Oddi Forge

Solana Token Safety Check

check_token

Check any Solana token (SPL or Token-2022) for red flags, read from public on-chain data: whether more tokens can be minted, whether holders can be frozen, Token-2022 tricks (transfer fees, permanent delegate, transfer hooks), copycat names of well-known tokens, mutable metadata and holder concentration. Returns findings with a level (bad, warn, ok) and plain-words explanations. No red flags never means a token is safe; this is not financial advice.

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": {
      "address": "<address>"
    },
    "name": "check_token"
  }
}

Input Schema

Name	Required	Description	Default
`address`	Yes	The token's mint (contract) address, base58, 32 to 44 characters

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 29, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does disclose the data source (public on-chain data), the exact behaviors inspected (mintability, freeze authority, Token-2022 extensions, copycat names, mutable metadata, holder concentration), and the result shape (bad/warn/ok levels with plain-words explanations). It does not mention rate limits, failure modes for non-token addresses, or whether results are cached.

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?

Front-loads verb and resource, then the checklist of checks, then two short caveats. The enumerated check list is long but each item is substantive; the disclaimer sentences earn their place by preventing over-trust in an 'ok' result.

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

Completeness4/5

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

With no output schema, the description correctly explains what is returned (findings with a severity level and plain-words explanation), which is the critical missing piece. Minor gaps remain around invalid/non-mint input handling, but nothing needed to call it correctly is absent.

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

Parameters3/5

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

There is a single parameter with 100% schema description coverage that already specifies base58, 32-44 characters, and mint address semantics. The description adds no further parameter guidance, so the baseline 3 applies.

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?

States a specific verb (check) and resource (any Solana token, SPL or Token-2022) and enumerates the exact classes of checks performed, so an agent can tell this apart from the sibling info tools (get_project_facts, get_team) at a glance.

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?

The scope 'check any Solana token' plus 'read from public on-chain data' gives clear context for when to invoke it, and the closing caveat sets expectations about interpreting results. It does not name an alternative tool or an explicit when-not condition, but among these siblings there is no competing token-analysis tool.

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

All Oddi Forge tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?