Skip to main content
Glama

token_verdict

Token rug check: is this token safe? Get an A-F grade, safety score, one-line verdict and plain-language take on any token on Base, Ethereum, BSC, Arbitrum, Optimism, Polygon, Avalanche or Solana. Built on the included full audit (live buy/sell simulation on 6 EVM chains, taxes, owner powers, liquidity, holders); the grade never comes from the AI. Plus a share page and card PNG. Risk screen, not financial advice. $0.015 USDC on Base. Failed calls are not charged. ($0.015 USDC on Base)

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": {
      "token": "<token>"
    },
    "name": "token_verdict"
  }
}

Input Schema

NameRequiredDescriptionDefault
chainNobase (default), ethereum, bsc, arbitrum, optimism, polygon, avalanche or solana.
tokenYesToken contract address: 0x-prefixed on EVM chains, base58 mint on Solana.
paymentSignatureNoOptional x402 v2 base64 PAYMENT-SIGNATURE

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.6/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 substantial work: it discloses the price ($0.015 USDC on Base), that failed calls are not charged, that grading is deterministic rather than AI-generated, that it runs live buy/sell simulation on 6 EVM chains, and that it emits a share page and card PNG. Gaps remain on latency, what the response looks like on a failed/low-liquidity token, and whether payment must be signed up front.

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

Conciseness3/5

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

The hook is front-loaded and the middle is information-dense, but it reads as one run-on marketing paragraph and the price is duplicated verbatim in a trailing parenthetical ('($0.015 USDC on Base)'), which is pure waste.

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 and no annotations, the description has to describe returns and it does: grade, score, verdict, plain-language take, share page, card PNG. Supported chains and payment terms are covered too. What is missing is error/edge-case behavior and cost-per-chain differences, which matter for a paid tool spanning eight chains.

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?

Schema coverage is 100%, so chain and token semantics are already fully documented in the schema; the description's chain list merely echoes it. It adds indirect context for paymentSignature by quoting the USDC price and the no-charge-on-failure policy, but never ties that to the parameter itself.

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

Purpose4/5

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

Names a specific verb and resource ('Token rug check: is this token safe?') and enumerates the concrete outputs: an A-F grade, safety score, one-line verdict and plain-language take. The phrase 'built on the included full audit' hints at how it relates to the sibling audit_crypto_token, but stops short of stating the distinction explicitly.

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

Usage Guidelines3/5

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

Usage is implied by 'Risk screen, not financial advice' and the supported-chain list, and the audit mention suggests this is the condensed read of the heavier sibling. However, nothing says when to pick this over audit_crypto_token, nor what prerequisites (payment setup) the caller needs before invoking.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.