Skip to main content
Glama

Token check

token_check
Read-only

Check a token before buying, sending or accepting it, on Base, Ethereum or Solana: what it is, its USD price and liquidity, and plain warnings read from the chain (no pool, thin liquidity; on Base and Ethereum the contract's owner and whether it is upgradeable or can mint, pause, blacklist or set fees; on Solana an active mint or freeze authority).

$0.004 USDC per call over x402. Failed calls cost nothing. Call without payment to get a quote.

When to use: Before buying, accepting or sending an unfamiliar token. Use instead: pretrade_check when you're about to trade a specific amount (adds price impact, your holding and news); token_info for the basics only. Parameters: token: ERC-20 contract or SPL mint. chain: base (default), ethereum or solana. Returns: what the token is, price and liquidity, and plain-language warnings (owner, upgradeable, can mint, pause, blacklist or set fees; Solana mint or freeze authority).

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_check"
  }
}

Input Schema

NameRequiredDescriptionDefault
chainNo"base" (default), "ethereum" or "solana".
tokenYesERC-20 contract or SPL mint to check.
paymentNoBase64 x402 payment payload. Omit it to receive a quote; sign that and call again.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses the x402 payment model, the $0.004 USDC per-call cost, that failed calls are free, and that omitting payment returns a quote. It also explains chain-specific checks such as owner, upgradeability, mint, pause, blacklist, fee-setting, and Solana mint/freeze authority.

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 description is front-loaded and organized into clear sections for purpose, pricing, usage, alternatives, parameters, and returns. It is slightly redundant because the opening paragraph already summarizes the return values that are repeated in the Returns section.

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?

For a read-only, open-world token-checking tool with no output schema, the description covers what is returned, chain-specific warnings, payment behavior, cost, and alternatives. An agent has enough information to decide when and how to call it.

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 description coverage is 100%, so the schema already documents token, chain, and payment. The description restates the token and chain meanings and adds the quote flow for payment, but does not add substantial syntax or format detail beyond the schema.

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 states a specific verb and resource: check a token on Base, Ethereum, or Solana, returning identity, USD price, liquidity, and chain-derived warnings. It clearly distinguishes itself from siblings by naming pretrade_check and token_info as alternatives.

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

Usage Guidelines5/5

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

It gives explicit when-to-use guidance: before buying, accepting, or sending an unfamiliar token. It also names the alternatives and the conditions that select them: pretrade_check for a specific trade amount and token_info for basics only.

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.