Skip to main content
Glama

Token facts read on chain

trnch_check
Read-onlyIdempotent

Read on-chain facts about any Elysium token before you trade it. Returns { token, chainId, screened: false, sellTest, hookFee, liquidity, creator, launchpad, template, forcedTransfer, meaning }: sellTest { class, result, blockedAt, complete, variantsRun, variantsSkipped, lossPct, method, sizes [{ amount, result, lossPct }], extraLossPctAtLargerSize, buyTaxPct, transfer { ok, backOk, taxPct }, sellLossPct, logsMatchBalances, delayed { clockAdvancedMinutes, result }, note }: a simulation at the time of the read that tries to buy, approve, transfer wallet to wallet and back, and sell from both wallets, as separate transactions, through the pools Trnch would route through (the proven launch pool, the deepest and the oldest qualifying pool; the worst result decides: decidingPool, poolTested, checkedAt), at two sizes and again with the clock advanced 5 minutes in simulation; note says in words what actually ran, complete, variantsRun and variantsSkipped say what did not and why, and a partial result reads "(partial check)"; class sold (bought, transferred and sold in a simulation, every step that ran succeeded), taxed, blocked (blockedAt says whether the approval or the sell failed in the simulation), transfer-failed (the tokens could not be moved between wallets in the simulation) or not-checked; buy tax, transfer tax and sell loss are reported apart, and token logs that do not match balances are reported. A simulation now: the token may behave differently later or towards other wallets, and an upgradeable or owner-controlled token can change; sizes 0.25 HYPE and, when the pool is deep enough, 1.5 HYPE; poolTested { id, feeBps, hook, launchpad, poolThinForSize, depthLowerBound }; decidingPool { id, roles, why }; poolsTested; poolsTruncated; checkedAt; hookFee { buyBps, sellBps } when the pool has a launch hook; liquidity { found, usdEstimate }; creator { launches }: how many tokens the same creator launched before this one; launchpad { result, hook, proof }: the launchpad of the pool tested, named only when proven ("Montra", "Boxa", "Kleos"; a verified contract name alone reads " (contract name)"), otherwise "hook not identified" or "no hook", a fact about origin, never a signal by itself; hookRisk { result }: what the hook of that pool can take, read on chain where readable: "launch fee window: up to N%, ends in M min", "hook tax: N% buy, M% sell" or "hook can tax up to N%", null when there is nothing to say; template { result, implementation, upgradeable }: "Montra template" when the token is a clone of that launchpad's token, "clone, template not identified", "upgradeable proxy" (its code can be replaced after the read) or "custom contract"; forcedTransfer { result, rolesTried, callsTried }: whether the declared owner or the creator could move or burn a buyer's tokens without approval in a simulation, trying only transferFrom without allowance and burn (other owner powers are not tried), "none found", "found: " or "not checked: ". A fact that could not be read says "not checked: ". Facts, not a verdict: Trnch runs no rug screen on this chain. No key needed.

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": "trnch_check"
  }
}

Input Schema

NameRequiredDescriptionDefault
tokenYesToken contract address on Elysium (chainId 99901).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior5/5

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

Annotations already cover read-only, idempotent, non-destructive, and closed-world behavior, but the description adds substantial context beyond them: it explains the simulation, partial-check semantics, dynamic token behavior after the read, and the explicit absence of a rug-screen verdict. It also notes no key is needed.

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

Conciseness2/5

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

The opening sentence is front-loaded and clear, but the rest is a dense, semicolon-chained prose schema that is difficult to scan. It is highly informative but far longer and less structured than it should be.

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, so the description must carry the return-value burden, and it does so thoroughly by enumerating fields, caveats, and simulation behavior. An agent has enough information to interpret the result and its limitations, even though the presentation is verbose.

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 only one parameter and schema coverage is 100%, including the address pattern and the Elysium chainId note. The description adds no additional meaning about the token parameter beyond the schema, so the baseline of 3 applies.

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?

The first sentence names a specific read operation on a specific resource (on-chain facts about an Elysium token) and positions it before trading. It does not explicitly name a sibling tool to contrast with, so differentiation from trnch_quote or trnch_scan_wallet is implicit rather than explicit.

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 clearly states the usage context: read this before trading and treat the output as facts, not a verdict. It does not explicitly say when to skip this tool or direct the agent to alternatives such as trnch_quote or trnch_buy, so guidance is clear but lacks exclusions.

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