Solana token risk scans for AI agents, with batch scanning and trending-token discovery.
Scored across 7 tools
Each tool has a distinct role: scanning (single vs bulk), discovery, credit checking, key registration, and two clearly labeled owner-only admin tools. The only mild overlap is scan_token vs scan_tokens, which are differentiated by the bulk limit and per-token cost in the descriptions.
Most names follow a predictable verb_noun snake_case pattern (add_credits, check_credits, register_free_key, scan_token, scan_tokens). Two deviants, admin_stats and trending_tokens, drop the verb but remain readable and unambiguous.
Seven tools is well-scoped for a token-safety + credit-billing service, with every tool earning its place. No redundant or filler endpoints.
The surface covers the core lifecycle: register a key, check credits, scan single/bulk tokens, discover trending tokens, and admin credit top-up plus stats. Minor gaps exist (no key rotation/revocation, credit usage history, or plan/pricing lookup), but agents can work around these.
OWNER ONLY: add credits to a customer's key after payment is received.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | No | paid | |
| api_key | Yes | ||
| credits | Yes | ||
| target_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a non-read-only, non-destructive, closed-world write, and the description adds the owner-only privilege requirement plus the payment precondition, which is real value. It does not disclose idempotency behavior, whether credits are additive to an existing balance, or what happens if the target key is invalid.
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 most important constraint ('OWNER ONLY') before the action and its precondition. Every clause earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations describing permissions, no output schema, and 0% parameter documentation, the description covers only authorization and timing. It omits the meaning of 'plan' and 'api_key' and gives no indication of what the call returns or how a partial/failed credit addition behaves.
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 0%, so the description must carry all parameter meaning, and it only implicitly maps 'credits' and 'target_key'. The 'api_key' credential and especially the 'plan' parameter (default 'paid') are never explained, leaving half the surface undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (add) and resource (credits) and identifies the target as a customer's key, which cleanly separates it from check_credits and the other siblings. It stops short of naming an explicit alternative, but the purpose is unambiguous.
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?
'OWNER ONLY' sets an authorization precondition and 'after payment is received' sets a timing precondition, both of which tell the agent when this tool is appropriate. No sibling alternatives or exclusions are named, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
OWNER ONLY: business overview — customers, calls, credits, plans.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint=false and destructiveHint=false, and the annotation title itself repeats '(Owner Only)', so the description's auth note is largely redundant with structured data. It adds no return format, aggregation window, or freshness information beyond the category list.
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 front-loaded line with the restriction first and the scope second — no padding or repetition. It is terse to the point of being a fragment rather than a sentence, which is efficient but borderline under-specified.
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 tool with no output schema, the annotations carry the safety profile and the description carries the scope, so the basics are covered. What is missing is any hint of the shape or granularity of the business overview an agent would receive.
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 one parameter (api_key) at 0% schema description coverage, and the description never mentions it or clarifies that it must be an owner-scoped key. Because api_key is a universally understood convention, the gap is tolerable but still uncompensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (business overview) and enumerates its scope — customers, calls, credits, plans — which lets an agent distinguish it from token/credit siblings like check_credits or trending_tokens. It lacks a concrete verb (does it just read, or recompute?) but the noun-level specificity is enough to identify the tool.
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 'OWNER ONLY' prefix states a real access precondition, which is usable guidance, but there is no explicit when-to-use vs. when-not or named alternative. An agent knows who may call it but not when it is the right choice over check_credits for the same subject matter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check remaining credits for an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: it does not say what is returned, whether an invalid key errors, or any rate/scope constraints, so it merely restates the annotation title 'Check Credit Balance'.
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 short sentence with the resource and target front-loaded and no filler. It is efficient, though its brevity is partly under-specification rather than genuine economy.
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 trivial one-parameter read tool with annotations covering safety, the minimum is met. However, there is no output schema and the description never indicates what a successful check returns (balance, remaining count, error state), leaving a real gap for an agent interpreting results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the single required api_key parameter has no schema description. The phrase 'for an API key' only loosely ties the argument to the operation and adds no format, source, or validity information to compensate for the coverage gap.
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 remaining credits for an API key.' It is distinguishable from the closest sibling add_credits (read vs. write), though it never names or contrasts with any sibling explicitly, so it falls short of the sibling-aware 5.
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 offers no when-to-use guidance, no prerequisites (e.g., key must be valid/registered), and no mention of alternatives such as register_free_key or add_credits. Usage is only inferable from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a free API key with starter credits. One per agent; paid top-ups available from the operator.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a non-read-only, non-destructive, closed-world write. The description adds genuinely new behavioral facts beyond them: the one-per-agent quota and that starter credits are granted, with paid top-ups handled externally. It does not say whether a key is returned in-band, whether registration is idempotent, or what happens on a second attempt.
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 compact sentences with the primary action front-loaded and the quota/alternative details trailing. Every clause carries information; nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter mutation with no output schema, the description covers purpose, quota, and the paid alternative, but leaves the agent guessing about the result (is an API key string returned? does it need to be stored?) and about failure behavior when the agent already has a key.
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 zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter-level detail is 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?
Names a specific verb (register) and resource (free API key) plus the qualifying benefit (starter credits), so an agent knows exactly what the call produces. Sibling differentiation is only implicit — 'free' vs. the paid 'add_credits' path — and no sibling tool is named directly.
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?
States a hard constraint ('one per agent') and indirectly routes paid needs to the operator's top-ups, which is useful selection context. However, it never says when to call this vs. add_credits/check_credits explicitly, nor whether prerequisites such as prior authentication apply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full safety scan of one Solana token mint: rug-pull risk score (0-100), verdict, mint/freeze authority, holder concentration, liquidity, pair age. Costs 1 credit. ALWAYS scan before buying a token.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| mint_address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the credit cost and the fact that this is an external-data risk lookup, which are genuinely useful and not in the annotations, though it says nothing about rate limits, caching, or freshness of the data.
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 core action and return fields, then a short cost note and a directive. Every clause earns its place and there is no padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only scan with no output schema, the description effectively enumerates the returned fields and notes the credit cost, which is enough for an agent to invoke it correctly. Minor gaps: the undocumented api_key and the absence of any note on data staleness.
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 0%, so the description must carry the load. It clarifies that mint_address identifies a single token mint, which is helpful, but it says nothing about the api_key parameter (its default, purpose, or how authentication works). Partial compensation only.
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 ('safety scan of one Solana token mint') and enumerates exactly what the scan returns (rug-pull risk score, verdict, mint/freeze authority, holder concentration, liquidity, pair age). The word 'one' plus the singular framing cleanly distinguishes it from the sibling batch tool scan_tokens.
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 clear usage guidance ('ALWAYS scan before buying a token') and discloses the cost ('Costs 1 credit'), which is actionable context. It does not, however, name the obvious alternative scan_tokens or state when the batch variant would be preferable, so the routing guidance is incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bulk scan up to 20 token mints. Costs 1 credit per token.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| mint_addresses | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so safety is covered. The description adds genuinely new operational context not in the annotations: a hard cap of 20 mints and a credit cost of 1 per token, which tells the agent this operation is billable and bounded.
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, both of which carry load: the first states scope and the second states cost. No filler, and the primary constraint is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only, 2-parameter batch tool the essentials are present, but with no output schema the description should at least hint at what a scan returns, and it leaves the undocumented api_key and mint address format unaddressed. Adequate but with clear gaps.
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 0% for both parameters. The description partially compensates by constraining mint_addresses ("up to 20") where the schema has no maxItems, but it says nothing about mint address format or the purpose/behavior of the api_key parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Bulk scan up to 20 token mints" gives a specific verb (scan), resource (token mints), and batch scope, which implicitly separates it from the singular scan_token sibling. However, it never names scan_token as the alternative, so differentiation is left to inference 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?
The word "Bulk" plus the 20-mint cap implies this tool is for multi-mint batches rather than single lookups, but the description never says when to use it versus scan_token or what to do with larger sets. Usage is implied, not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest boosted/trending Solana tokens on DexScreener. Costs 1 credit. Tip: scan_token any candidate before trading.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds a genuinely non-structured trait: a fixed cost of 1 credit, which an agent needs for budgeting decisions. It does not disclose result limits, freshness, or rate 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?
Two short sentences, front-loaded with what the tool returns and the cost, followed by an actionable tip. 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?
No output schema exists, yet the description never characterizes the return payload (fields per token, count/limit, ordering). Cost and the sibling workflow are covered, so it is viable for a simple list tool but leaves the agent guessing about result shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter (api_key) has zero schema description coverage, so the description would need to compensate and does not mention authentication at all. The parameter name is largely self-explanatory, but there is no hint that a key is required or that register_free_key/check_credits siblings exist to obtain one.
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 (boosted/trending Solana tokens) and its source (DexScreener), which no sibling claims. The differentiation from scan_token is implied via the workflow tip rather than stated outright, and the retrieval verb ('latest') is mild.
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?
Sets clear context (surfacing trending candidates) and recommends a concrete follow-up: 'scan_token any candidate before trading.' It does not state when NOT to use the tool or contrast it with scan_tokens (plural), but the workflow positioning is explicit enough to route an agent.
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.
add_creditsadmin_statscheck_creditsregister_free_keyscan_tokenscan_tokenstrending_tokensSolana token safety for AI agents — rug-pull, honeypot & Token-2022 trap detection before you buy.
RiskDataApi — Solana token risk scoring for AI agents. Safety score, insider clusters, honeypot.
Token rug-risk scans, Know Your Agent wallet checks and deployer reputation for AI agents.
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.