Skip to main content
Glama

Token Units

token_units
Read-onlyIdempotent

Exact (string-math, no floating point) conversion between human token amounts and on-chain base units: wei / gwei / ether, lamports / SOL, sats / BTC, USDC/USDT (6 decimals) or any token with a decimals value. Returns the converted amount, the integer base units (decimal and hex) and every unit of the family. Accepts decimals, scientific notation and 0x-hex raw amounts. Price: $0.001 USDC per successful call (x402, Solana). Same tool over HTTPS: GET https://scorptech.it.com/api/x402/v1/token-units

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": {
      "amount": "<amount>",
      "from": "<from>",
      "to": "<to>"
    },
    "name": "token_units"
  }
}

Input Schema

NameRequiredDescriptionDefault
toYesTarget unit
fromYesUnit of amount (raw = integer base units)
amountYesAmount: 1.5, 2e-6, 1500000, or 0x-hex (base units)
decimalsNoToken decimals, needed for unit "token" (and for raw <-> token)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely non-redundant behavior: conversions are exact with no floating point, a per-call price of $0.001 USDC via x402 on Solana applies only to successful calls, and an HTTPS fallback endpoint exists. That cost/auth-adjacent disclosure is exactly the kind of detail annotations cannot carry.

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-loaded with the core purpose, then return values, accepted formats, price and endpoint — each clause carries information. It is dense but not padded; the endpoint URL and pricing sit last where they belong.

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?

With no output schema, the description compensates by describing what comes back (converted amount, integer base units in decimal and hex, every unit of the family). Combined with input-format and pricing notes, an agent has everything needed to call it correctly.

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% and the enums are fully documented, so the schema already carries the parameter burden. The description reinforces input formats (1.5, 2e-6, 1500000, 0x-hex) and hints that decimals is needed for token conversions, but adds little beyond what is already in the field descriptions.

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 (exact string-math conversion between human token amounts and on-chain base units) and enumerates the unit families covered, which cleanly separates it from lookalikes such as unit_convert, currency_format and base_convert.

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 gives clear context for use (any token with a decimals value, raw hex input, scientific notation) and states the commercial terms, so an agent knows what this call is for. It does not explicitly say when to prefer this over unit_convert or other conversion siblings, nor name any exclusion.

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.

Resources