YourAITools MCP Hub

SolVerdict: Solana token safety check

check_solana_token

Read-onlyIdempotent

Safety check for any Solana SPL or Token-2022 mint before an agent or app interacts with it. SAFE / CAUTION / DANGER with a 0-100 score, from mint and freeze authority, Token-2022 extensions that can block or tax sells, liquidity and recent sells, holder concentration and age. Free preview tier: verdict, score and flag counts. The paid x402 endpoints /v1/lite ($0.005) and /v1/check ($0.02) add the reasons and evidence. SAFE is not a guarantee and not financial advice.

[SolVerdict via YourAITools MCP Hub] Free tier: same as SolVerdict's own MCP server (call without payment and without tier). Paid: lite $0.005 / check $0.02 per call, with a credits key (Authorization: Bearer yatc_...) or x402 (USDC; the hub returns the payment terms). Failed tool calls aren't charged: credits are refunded automatically and x402 payments only settle on success.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "mint": "<mint>"
    },
    "name": "check_solana_token"
  }
}

Input Schema

Name	Required	Description	Default
`mint`	Yes	Solana token mint address (base58), e.g. DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263 (BONK)
`tier`	No	Paid tier: lite $0.005, check $0.02. Omit tier (with no credits key or x402 payment) to use the free tier.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026
- addedInput schema / properties / mint / examples
```
Added value: +[
+  "DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263"
+]
```
First observedOct 24, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well past them: it discloses the return shape (SAFE/CAUTION/DANGER plus a 0-100 score), what changes between free and paid tiers, exact pricing, both payment paths, and that failed calls are refunded or never settled. It even flags the interpretive limit that SAFE is not a guarantee — exactly the context an agent needs to use the verdict responsibly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The verdict, score and evaluated factors are front-loaded before pricing, which is the right order. The bracketed hub paragraph is denser and more operationally repetitive than it needs to be for a model choosing a tool, costing it the top score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description compensates fully by describing the returned verdict levels, numeric score, what the free tier returns versus what lite and check add. With only two simple parameters and full annotation coverage, nothing needed to invoke or interpret the call is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema by explaining what the paid tiers unlock (reasons and evidence) and confirming that omitting tier with no credentials falls back to free. That resolves the main ambiguity an agent would face when deciding whether to pass a tier.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource — a safety verdict on a Solana SPL or Token-2022 mint — and enumerates the exact inputs it evaluates (mint/freeze authority, Token-2022 extensions, liquidity, holder concentration, age). That specificity distinguishes it from generic siblings such as check_token or scan_tools without needing to name them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the triggering condition clearly: run this 'before an agent or app interacts with' the token. It also spells out the tier decision tree (omit tier with no key/payment for free; lite vs check for reasons and evidence). The one gap is that it never points to the closest sibling alternative, e.g. when a non-Solana token should go to check_token.

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

All YourAITools MCP Hub tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?