Check before money moves. Lorg Check tells an AI agent, or you, whether a token is a trap or an address is unsafe to pay, on Base and Ethereum. In live tests on new launches it blocked traps that GoPlus and Honeypot.is missed. Call check_token before buying or swapping into a token: it simulates a real buy and sell-back through the token’s own pool, reads what the creator can still do, who can pull the liquidity, and whether the creator was paid by a wallet behind earlier rugs. Call check_address before sending funds: sanctions, scam labels, EIP-7702 sweepers and address-poisoning look-alikes. Every answer is signed and says proceed, limit_exposure or do_not_proceed, with a one-line summary to show the user. Free key by GitHub sign-in, or connect with an API key.
Scored across 2 tools
check_address targets wallets/addresses while check_token targets tradeable tokens, and each description explicitly routes the other case ('For a token you intend to buy, use check_token instead'). An agent can decide unambiguously based on what it is about to do (transfer vs. swap).
Both names follow the same verb_noun snake_case pattern with the shared 'check_' prefix, making the pair read as a coherent family. No mixed conventions or stray verbs.
Two tools is on the thin side, but the service has exactly two entity types to vet (addresses and tokens) and each tool is substantive rather than trivial. Nothing redundant is present, though a slightly broader surface (e.g. approvals or transactions) would make the count feel fuller.
The core pre-transaction safety workflow is covered: vetting a recipient address and vetting a token before a swap, including verdicts, reasons and cross-references between the two. Gaps exist around spender/approval checks, transaction or calldata simulation, and newer token standards (e.g. NFT collections), which an agent cannot work around within this surface.
Is this address safe to send funds to? Checks sanctions lists, known scam labels, wallets that forward everything they receive to a thief (EIP-7702 sweepers), look-alike addresses made for address poisoning, and where the wallet's first funds came from. Returns a signed verdict (allow, caution or block), an action, a one-sentence summary and the reasons. Use it before a payment or transfer on Base, Ethereum, Arbitrum, Robinhood Chain, Polygon or BNB Chain or Solana. For a token you intend to buy, use check_token instead. Typically half a second.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | The chain the address is on. | |
| address | Yes | The wallet or contract address: 0x followed by 40 hex characters, or on Solana a base58 address (case matters). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false), so the description's job is to add context, and it does: it lists the signal sources checked and describes the returned verdict (allow/caution/block), action, summary and reasons, plus typical latency. It stops short of stating auth requirements or rate limits, which keeps it at a 4 rather than a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It leads with the decision question, then the evidence, then the return contract, then usage and the sibling alternative. Every sentence carries load and none are filler, despite the density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description explicitly enumerates the return payload (signed verdict, action, one-sentence summary, reasons), so an agent knows what it will receive. Combined with the explicit chain coverage and the sibling routing, nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the address field already documents both the 0x and base58 formats, so the schema does the heavy lifting. The description restates the supported chain set, which largely duplicates the enum rather than adding syntax or edge-case semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening question plus the explicit list of what is checked (sanctions, scam labels, EIP-7702 sweepers, poisoning look-alikes, funding source) states a specific verb and resource, and it names the sibling it is not ('For a token you intend to buy, use check_token instead'). An agent can distinguish it from check_token without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says exactly when to call it ('before a payment or transfer'), enumerates the supported chains, and routes the token case to the alternative tool. Nothing about when-to-use or when-not-to-use is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Is this token safe to buy? Runs a simulated buy and sell-back through the token's real pool, and reads what its owner can still do, who can withdraw the pool's liquidity, its holders, its deployer and whether it imitates a known token. Returns a signed verdict (allow, caution or block), an action (proceed, limit_exposure, do_not_proceed), a one-sentence summary and the reasons, most serious first. Use it before every swap into a token on Base, Ethereum, Arbitrum, Robinhood Chain, Polygon or BNB Chain or Solana. Typically 1.3 seconds for a token checked from scratch; much faster for one checked moments earlier.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | The chain the address is on. | |
| address | Yes | The token's contract address: 0x followed by 40 hex characters, or on Solana the token's mint address (base58, case matters). | |
| amount_usd | No | Optional: your trade's size in US dollars. The check then also buys and sells that amount in simulation, and says so (EXIT_LIQUIDITY_INSUFFICIENT) when the pool or the token can't take it. Give it whenever you know the size. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false; the description adds real substance on top: the check is a simulation against the live pool (not an actual buy), it discloses what sources it inspects, it explains the returned verdict/action structure, and it gives expected latency (~1.3s cold, faster when cached). Nothing contradicts the readOnly annotation because the trade is explicitly described as simulated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It opens with the decision the agent cares about ("Is this token safe to buy?"), then gives the mechanism, the return shape, the usage trigger and the performance profile in that order. Every sentence carries distinct information; nothing is padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 has to describe return values, and it does: signed verdict (allow/caution/block), an action (proceed/limit_exposure/do_not_proceed), a one-sentence summary and reasons ordered by severity. With annotations covering the safety profile and the schema covering all three parameters, nothing an agent needs is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so chain, address and amount_usd are already fully documented in the schema, including base58/hex formats and the amount_usd bounds. The description adds only indirect meaning by enumerating the supported chains in prose, which mostly restates the chain enum, so baseline 3 is right.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource (simulated buy/sell-back through the token's real pool, plus owner/liquidity/holder/deployer/imitation checks) and frames it as a safety verdict. An agent can immediately tell this is a token risk check rather than an address lookup, which is what the sibling check_address implies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use it before every swap into a token on Base, Ethereum, Arbitrum, Robinhood Chain, Polygon or BNB Chain or Solana" gives clear, concrete context for when to call it, and the latency note tells the agent that repeat calls are cheap. It does not name the sibling check_address or state when not to use this tool, so no alternatives or exclusions are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_address3 fields changedInput schema / properties / address / descriptionPrevious value: -"The wallet or contract address: 0x followed by 40 hex characters."New value: +"The wallet or contract address: 0x followed by 40 hex characters, or on Solana a base58 address (case matters)."Input schema / properties / address / patternPrevious value: -"^0x[0-9a-fA-F]{40}$"New value: +"^(0x[0-9a-fA-F]{40}|[1-9A-HJ-NP-Za-km-z]{32,44})$"Input schema / properties / chain / enumPrevious value: -[
- "base",
- "ethereum",
- "arbitrum",
- "robinhood",
- "polygon",
- "bnb"
-]New value: +[
+ "base",
+ "ethereum",
+ "arbitrum",
+ "robinhood",
+ "polygon",
+ "bnb",
+ "solana"
+]check_token4 fields changedInput schema / properties / address / descriptionPrevious value: -"The token's contract address: 0x followed by 40 hex characters."New value: +"The token's contract address: 0x followed by 40 hex characters, or on Solana the token's mint address (base58, case matters)."Input schema / properties / address / patternPrevious value: -"^0x[0-9a-fA-F]{40}$"New value: +"^(0x[0-9a-fA-F]{40}|[1-9A-HJ-NP-Za-km-z]{32,44})$"Input schema / properties / amount_usd / descriptionPrevious value: -"Optional: the size of the trade you intend, in US dollars. The check then also buys and sells that amount in simulation, and says so (EXIT_LIQUIDITY_INSUFFICIENT, action limit_exposure) when the pool is too small for it or the token limits the size of a sale. Give it whenever you know the size."New value: +"Optional: your trade's size in US dollars. The check then also buys and sells that amount in simulation, and says so (EXIT_LIQUIDITY_INSUFFICIENT) when the pool or the token can't take it. Give it whenever you know the size."Input schema / properties / chain / enumPrevious value: -[
- "base",
- "ethereum"
-]New value: +[
+ "base",
+ "ethereum",
+ "arbitrum",
+ "robinhood",
+ "polygon",
+ "bnb",
+ "solana"
+]check_address1 field changedInput schema / properties / chain / enumPrevious value: -[
- "base",
- "ethereum"
-]New value: +[
+ "base",
+ "ethereum",
+ "arbitrum",
+ "robinhood",
+ "polygon",
+ "bnb"
+]check_addresscheck_tokenPre-trade token safety check for AI agents. Simulates a sell before you buy, then returns one low/medium/high/unknown verdict with the signals behind it: sellability, buy/sell tax, liquidity depth, pair age, same-ticker impersonation, owner powers from bytecode. Ethereum, BSC, Base, Solana. Fail-closed - a check that cannot run answers unknown, never low. Publishes its own measured error rate with the benchmark harness in the repo. Free, no signup, no API key, MIT.
Check a Base contract, transaction or web page before you act. Free pricing, paid per call in USDC.
Pre-trade token safety checks for AI agents on Solana and Base. x402 USDC per call, no key.
Token rug-risk scans, Know Your Agent wallet checks and deployer reputation for AI agents.
Add one secure layer between your agents and this server.
