Recognizes Calendly as a legitimate scheduling platform to reduce false positives in luring detection.
Correctly identifies Google Meet as a legitimate service, avoiding false impersonation flags in domain checks.
Interprets Optimism chain IDs in transaction calldata for blockchain forensic tracing across networks.
Detects impersonation of WeChat domains to identify phishing attempts in communication analysis.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@onchain-forensics Check rug pull risk on 0xabc123def456"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Twelve checks you run before you pay, and after you've been robbed. Exposed as an MCP server so an agent can call them, and as plain modules so you can call them yourself.
No API keys. No accounts. Every source is a public endpoint. Read-only throughout — nothing here can move funds, and none of it will ever ask you for one.
It was written in one sitting, while tracing a real theft. Someone's wallet was drained on Base; the trail went through a DEX, a bridge, and out to TRON. Each tool here answers a question that came up during that trace, and each one was kept only after it reproduced a fact already established by hand.
That origin matters more than the feature list. Where a check turned out to be wrong, the fix and the reason it was wrong are written into the module. Those comments are the useful part of this repository — they are the difference between a scanner that sounds confident and one you can act on.
Three examples, all real, all caught by testing against known answers:
The bridge exit carried 0x2b6653dc, which reads as a perfectly plausible token amount. It is chain id
728126428 — TRON mainnet. Reading it as a quantity produced a confident wrong answer, which is the
worst output a forensic tool can give.
A one-byte chain id matched inside calldata padding and reported Optimism on a transaction that went to TRON. Ids under two bytes are now returned separately as unusable rather than as evidence.
The curated security index reports holder_count: 0 on a freshly indexed token, meaning "not computed
yet" rather than "no holders". Read literally, it stamps a warning on every new launch — which is exactly
the noise that makes people stop reading warnings.
Related MCP server: Onchain MCP Server
Tool | The question |
| Which contract is the real one behind this ticker? |
| What powers does the deployer still hold over my money? |
| Real Base-native asset, or an ERC-20 wearing its address prefix? |
| Who paid for this launch, and what else did they pay for? |
| Where did the stolen funds go? |
| Is this offer to get my money back the second theft? |
| Is this inbound opportunity a lure? |
| Which doors into my wallet are still open? |
| What changed around this wallet since we last looked? |
| Is this agent safe to connect to, and safe to pay? |
| Is a recovery phrase sitting in cleartext on this machine? |
| What key material is on this disk, and what still holds an old copy of it? |
A dangerous capability only counts if someone can still fire it. is_mintable with ownership renounced
is inert; the same flag with a live owner is an armed rug. Scanners that list flags without that distinction
produce noise, and noise gets ignored, and ignored warnings are the same as no warnings. Proven on a live
token: BRETT reports a modifiable tax and unlocked LP, and is not a rug, because nobody can fire either.
An event is not a transaction. ERC-20 Transfer logs are strings the emitting contract chooses. Spam
contracts routinely emit transfers naming addresses that never signed anything — during the trace this came
from, a bot forged a fake transfer four minutes after the real theft, using a token named EṬH (a Unicode
homoglyph) and an address engineered to look like the victim's. Any tool that reads "transfers where
from = target" straight from an indexer will report movements that never happened. Check the signer.
An earlier version of this README and of rugsignals.js claimed that the rugs observed while building
this all died by liquidity withdrawal, and that the unlocked-LP flag had already been printed on each
verdict. That was checked against the stored evidence and it is false. Not one of the eight rugs carried
that flag. Seven carried a single flag and it was the holder count; the eighth had no data at all. The
unlocked-pool flag appeared on tokens that survived.
The claim had been generalised from two examples that fit the story and neither of which rugged. It was plausible, mechanically sound, and wrong — which is exactly the shape of the errors this repository is meant to catch, so it stays documented rather than quietly edited away.
vet_approach, and why it refuses to grade how convincing something isThe lure that started this repository was not phishing in any recognisable sense. It was a 35-question production dossier across six chapters, with per-chapter shot lists, citing the target's real scoring model and settlement rails, using his own catchphrase back at him, and quoting his posts verbatim.
It also asked genuinely hard questions — whether one score creates false certainty, whether the oracle profits from generating fear. That was the payload, not the praise. A flatterer never includes criticism, so including it is exactly what flips an approach from marketing into journalism in the reader's head.
The mechanism underneath is effort as a trust signal. Producing that much researched detail used to cost hours of human work, so nobody spent it to scam one person, and every reader's instinct silently priced that in. The arithmetic held for decades. It does not hold now — the same document generates in minutes from a public profile — and nobody updated their instincts.
So this tool deliberately does not score how convincing an approach is. Convincingness is manufacturable, and
grading it would hand a forgery a good mark. It grades the two things a forger cannot make harmless: where
a link actually points, and what the sender wants you to do. A brand name to the left of the
registrable domain is a free label — wechat.web09eu.com is web09eu.com.
The false-positive test earned its keep on the first run: a version keyed on brand names alone flagged
meet.google.com — Google Meet, the real one — as impersonation. A tool that warns about Google Meet is a
tool people uninstall.
The domain in that approach is still live months later, so it could be replayed against the module written because of it. That is the only test worth much on a tool like this, and it found more than it confirmed.
The stated rule was not the implemented rule. The output printed "a real podcast records in your
browser" while nothing in the code applied it. vetApproach took booleans — asksToInstall, asksForSeed —
so the caller had to have already decided that the message asks you to install something. That is the hard
part. It made this a checklist rather than a check: fine for a careful human, useless to an agent handed a raw
email. It now accepts message and reads the ask out of the text, and the composition is fail-closed by
construction — the scan can only ever add a flag, never clear one a caller set deliberately, because a
heuristic may accuse and must never acquit.
calendly.com was reported as "not a platform this recognises" — the meet.google.com mistake again,
wearing different clothes. And the fix is the interesting part: in the real approach, the Calendly link was
genuine. A real account on a real service. So Calendly is neither a flag nor a comfort, and it now returns
recognised_neutral with that said out loud — legitimate infrastructure is the cover, not the tell. A brand
sitting under a domain that does not own it is still impersonation; calendly.evil.com is a row in the test.
The headline was the weaker of two true findings. reason was flags[0] — whichever check happened to
push first — and on the real message that surfaced "a link points at a domain that is not a recognised
platform" while burying "they want the conversation moved into a chat app to hand you a file". Both were
reported; only one is worth acting on. Push order is not a priority, and on a security tool the first line is
what the reader acts on, so the most specific flag now leads.
Worth stating because it is the opposite of a triumphant demo: replayed on the email text alone, the verdict is
high_risk, not fraud. That is correct rather than a miss. Nothing in that message is provably
fraudulent — it is the wechat.web09eu.com link that is, and adding it flips the verdict. A tool that cried
fraud on the text would have been right by luck, and would cry fraud on real podcast invitations too.
Two of the three "defects" I first reported here were my own misuse: registrableDomain takes a hostname and
I passed it a URL, and vetApproach takes booleans and I passed prose. The code did exactly what it said. But
a public helper whose most likely misuse returns silent garbage — https://beaconlayer.co/ in, the whole URL
back out, no throw — is a defect anyway, because nobody re-reads a docstring to check an answer that looks
fine. It accepts a URL, a hostname or an email address now.
recovery_offerThis is the only tool here that can answer with certainty rather than a score, and it is the one most likely to matter to someone reading this after a bad day.
Recovering stolen funds happens through the thief returning them, or a court, an exchange, or a token issuer freezing and reassigning them. None of those routes require anything from the victim's wallet. So a recovery that needs your signature or an upfront fee is not merely suspicious — it is structurally impossible as described. That holds no matter how credible the person sounds, and no matter how accurately they recite your loss back to you: the theft is public, and reciting it proves nothing.
The tool never returns "safe".
open_approvals, and the all-clear it fabricated in its own first draftAn ERC-20 approval is a standing permission to move your tokens without asking again. It is the most common drain route that does not need your private key: approved once for an unlimited amount, months ago, to a contract you no longer remember. Wallets do not surface these.
The load-bearing rule is that an Approval event is not the current state. A later approval of zero
revokes an earlier one and emits its own event; reading the log gives you a list of doors that may or may not
still be open. So the log is used only to collect candidate (token, spender) pairs, and every pair is then
confirmed by calling allowance() on the chain right now.
My first draft of this counted a failed RPC call as a revoked approval. It reported forty closed doors having actually verified nine — a fabricated all-clear, on the one tool whose entire job is telling you what is still open. I had documented that exact fault in someone else's scanner an hour earlier.
The fix is four outcomes rather than two: live, confirmed-revoked, not-applicable (the call reverted,
which is a definitive answer), and could-not-check. That last state is the whole point — an unanswered call
is not a closed door, and the tool now says so and reports complete: false.
Then the unread count was driven to zero for real, by batching every allowance() into one aggregate3
call through Multicall3 — one request instead of dozens, so the rate limiting that caused the unread calls
stops happening. Verified against a live wallet: 11 unread became 0.
watch_wallet, and why a monitor that repeats itself is worth nothingEvery other tool here answers at a point in time. This one remembers, which is what turns them into a guard.
Three unlimited approvals granted last year are a standing condition. A fourth appearing this morning is an event. Only the second deserves to interrupt anyone — a monitor that re-reports its standing conditions every hour trains its reader to close it, and a closed monitor catches nothing. So state is persisted per address and the output is a diff.
It also judges each new counterparty instead of merely announcing it, because detecting and then declining to think is half a product. And it reports its own blind spots on every run: on a wallet monitor, an empty alert list reads as "you are safe", so a check that could not run has to say so out loud.
vet_agent, and why it will not grade a tool descriptionAgents now call other agents and pay them. Four dangers are checkable without trusting a word of the listing: it does not exist; its tools can move money; it asks for key material; or it is paid to an address with no past.
The discipline that made this work is that a name is marketing, the input schema is the capability. A
tool called helpful_assistant with an amount field and a to field is a payment tool. And only a
quantity field proves a payment surface — a message has a recipient exactly as a payment does, but you
cannot move value without saying how much. Keying on recipients alone flagged our own messaging tool.
Two bugs worth repeating because both produced silent passes. A word-boundary regex (\bsend\b) matched
none of nine snake_case tool names, because an underscore is a word character — wallet_transfer never
matches \btransfer\b. And an HTTP 401 was first classified as unreachable, when it means the opposite: the
agent is running and gated. That is unauditable — neither a pass nor a fail.
It deliberately does not score how good the description reads, for the same reason vet_approach does not:
a well-written tool listing is free to fabricate, and grading prose hands a forgery a good mark.
And then it flagged our own server, which is how the rule above got finished. The first version returned
high_risk on a live endpoint because one of its 43 tools takes an amount. Reading the handler showed that
tool holds no key and broadcasts nothing: it requires an EIP-712 signature the caller has to produce.
A payment surface only counts against an agent if the agent can fire it. A tool gated on a caller-supplied
signature is the agent-tool equivalent of a contract with ownership renounced — the capability is there and
nobody unattended can trigger it. That is the same rule rugsignals.js had been applying to contracts since
day one, and vet_agent was not applying it. The second use of a principle deserves as much scrutiny as
the first; I had written it down and still missed it.
The gate is narrow on purpose, because a loose reading of it would excuse every drainer with an auth header:
the field must be required, not merely accepted — an optional signature gates nothing;
it must authorize the caller. An apiKey authorizes the agent: a standing credential it already
holds, which is exactly the unattended case being tested for.
Those two evasions and three more are rows in test/agent-vet-gate.js, because a gate nobody tried to walk
through is not a gate. A gated surface never escalates and is never dropped either — it is reported on
every verdict including the clean ones, since "we found a payment tool and decided it was fine" is a
conclusion the reader is entitled to disagree with. What the check cannot see is whether the server actually
verifies that signature; that is off-chain code, so it is reported as a described gate and never as proof of
one.
Auditing the rest of our own endpoints then surfaced a second category: a tool that takes an amount to
record a payment that already happened. A required transaction hash is a backward reference — a hash
cannot be broadcast — where a required raw signed transaction is forward-acting and is exactly how funds
move. That line is the whole distinction, and the sharpest row in the truth table is the one asserting that
signedTx is never read as a witness merely because it contains the letters tx.
The residual risk of a witness tool is named rather than dissolved: it can claim a payment that did not happen. That is a false-record risk, not a drain risk, and a check about unattended spending has no business pretending to cover it.
Both categories were found by pointing the tool at our own servers, which is also the reason to distrust them
a little: a false-positive story is most tempting when the flagged thing is yours. The test applied to each
was whether the reasoning would be accepted for a stranger's server. Two other bugs found the same way are
recorded in the module — a hardcoded verdict line that claimed no tool named a value-moving action while the
surface field in the same response listed two that did, and a set entry (signedtx) that could never match
because tokenize splits it into signed + tx. That last one is the third time in this file that
splitting an identifier silently disabled a rule.
GitHub trending surfaced a project whose pitch is that your agent inherits your existing logins, cookies and
extensions — your real Chrome profile, with in-page tools named snapshot, fill, click, wait,
navigate, capture. Pointed at it, vet_agent reported a read-only surface. Correctly, by its own rules: a
value VERB is required in a name before the schema is examined at all, and browser automation has none by
design. fill even carries a value field, and it is never reached.
The danger is not in any tool. It is in what the browser can reach. On the machine this was tested from,
key_exposure reports eight browser wallet vaults on disk, one of them 27 MB of MetaMask state. An agent
that can navigate and click inside that profile can drive the wallet, which is a payment surface no input
schema will ever advertise.
So the check flags the combination, never browser control alone — the same tools against a clean container
are ordinary web automation, and flagging those is how a security tool gets muted. The second half is
checkable: localVaults is passed in by the caller, and comes from the vault sweep.
Getting the detector right took two wrong versions, both kept as test rows because they are the interesting
part. Keyed on VERBS, it fired on five of six honest tool sets — a trading agent (open_position +
execute_order), a file manager, a database client, a terminal, a CI runner — because open and execute are
the two most generic verbs in software. Keyed on names and schemas, it then MISSED our own Chrome MCP, whose
action tools are called computer and form_input while taking ref and coordinate: a false negative, which
on a security check is the worse direction. A DOM field decides alone now. A selector or a coordinate exists
for exactly one purpose — addressing something rendered. open_file takes a path, execute_query takes sql,
open_position takes a size, and a git checkout takes a ref that is a branch; none of them touch a DOM,
which is why the weak fields like ref only count inside a tool set that also navigates.
(This paragraph shipped once with every backticked identifier missing — "in-page tools named , , , ," — because it was written through a shell heredoc where backticks are command substitution. Fixed in the next commit. Documenting it because the same class of mistake, a tool used through a layer that silently eats part of the input, is what the rest of this file is about.)
seed_exposure, and the false positive it produced on its first real machine"Self custody if you know how to keep your seedphrase safe." The condition is the whole sentence, and nothing ships that checks it. An antivirus answers do you have a known virus; the question a person holding crypto actually has is is my recovery phrase readable by anything that runs here.
That question is decidable, which is the only reason this is worth building rather than guessing at. A
keyword scan drowns immediately — abandon, able, about and absent are ordinary English and all four are
BIP-39 words. But a mnemonic is not a bag of words. It is a run of 12/15/18/21/24 consecutive words drawn
from a 2048-word list, and BIP-39 puts a checksum in the last word:
word indices (11 bits each) → entropy bits ‖ checksum bits
checksum must equal the leading bits of SHA-256(entropy)So a candidate is proven by arithmetic, not scored. Measured on 1.6 MB of real English prose and source across 204 files: zero confirmed hits.
It never outputs the phrase. Not to stdout, not to a log, not in an error. It reports the file, the line and the word count. This output ends up in terminal buffers, CI logs, screenshots and pasted bug reports, none of which is a place a seed belongs — a scanner that prints the seed it found is a stealer with good intentions, and good intentions are not a security property. The location is enough to act on: go and look.
Then it was pointed at a real machine and returned exposed, wrongly. The hit was inside a paywall template
that embeds a minified wallet library, and the library embeds all 2048 BIP-39 words. A 15-word window in that
region passed the checksum by chance.
The bounded offset search was written to prevent precisely that, and it worked — on the axis I had thought about. Minified code splits the wordlist region into thirty-odd separate runs, and each run then gets its own bounded search: roughly 600 checksum tests in one file, at 1/16 each for a 12-word window. A coincidental pass there is not a risk, it is arithmetic. I had capped the multiplicity inside a run and left the number of runs unbounded — the same problem rotated ninety degrees.
The fix is that the file carries its own refutation. A note holding a seed contains 12 to 24 wordlist words; a wallet library contains hundreds. Above 200 distinct wordlist words the file is a carrier — a library, a language pack, or the list itself — and no phrase is claimed inside it. Both halves are tested: the carrier is never confirmed, and a long document that also contains a real phrase still is.
What it cannot see, said plainly, because on this question silence reads as safety. No images, no PDFs, no
password managers, no browser storage, no encrypted archives, nothing outside the paths given. nothing_found
means nothing was found in what was read — the result carries complete and a per-reason skipped count so
a partial scan can never be mistaken for a clean bill of health.
npm test runs test/publishable.js, which refuses to call this repo publishable unless every relative
require resolves to a file that is here, lib/index.js exports every entry point, and the MCP server boots
over real stdio and lists all ten tools with usable schemas.
It exists because of one specific failure. lib/wallet-watch.js was copied in from the private repo it was
written in, carrying require('./screen') for a file that never came with it. The whole server then died on
load — every tool gone, not just that one. The smoke test I had run passed, because I ran it before
adding that dependency and then copied the changed file over without re-running it.
A stale test feels exactly like a passing one. That is why the correction here is a gate and not a resolution
to be more careful. The gate's rule is asymmetric on purpose: a require may resolve to nothing only if
the line says optional-require, so an absence has to be claimed in the source to be tolerated and silence
means broken. And a marker that claims optional while sitting outside a try is reported as a lie, because a
marker nobody verifies is just a comment. Both failure modes were reproduced deliberately to confirm the gate
catches them.
git clone https://github.com/philpof102-svg/onchain-forensics
cd onchain-forensicsNo dependencies to install — it uses only the Node standard library. To check the clone is intact:
npm testThat boots the server and verifies all ten tools list, so a broken copy fails here rather than in your client.
claude mcp add onchain-forensics -- node /absolute/path/to/onchain-forensics/bin/onchain-forensics-mcp.jsOr in any MCP client's config:
{
"mcpServers": {
"onchain-forensics": {
"command": "node",
"args": ["/absolute/path/to/onchain-forensics/bin/onchain-forensics-mcp.js"]
}
}
}const { scanRugOne } = require('./lib/rugsignals');
const { classifyB20 } = require('./lib/b20');
const { followTron } = require('./lib/trace');
const v = await scanRugOne('base', '0x...');
console.log(v.verdict, v.reason); // rug_ready | high_risk | caution | clean | unknownBlockscout (EVM chains) · TronGrid (TRON) · DexScreener (liquidity) · GoPlus (contract security) · honeypot.is (live trade simulation). All keyless, all public, all rate-limited — the code throttles and caps its own crawls, because being rude to a free endpoint is how everyone loses access to it.
It reports structure, never identity or intent. A shared funder proves shared control or shared infrastructure; a launchpad and a rug factory are indistinguishable from the graph alone. An amount-matched forward proves a pass-through; it says nothing about who holds the keys.
Every verdict is a pointer to the chain, not a badge. Re-verify.
MIT.
Is this a genuine Base-native B20 asset, or an ordinary ERC-20 wearing its address prefix? B20 is Base's standard for compliant issuance (stablecoins, RWA); its tokens sit at 0xb200… and run as a precompile, so a real one carries almost no EVM bytecode. As people learn to read that prefix as "official", a vanity-address ERC-20 inherits the credibility for free. Both answers matter: an impostor lacks the issuer controls the standard implies, and a GENUINE B20 lets its issuer freeze and burn a blocked holder's balance — a power no ERC-20 has and no ERC-20-shaped scanner looks for.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | ||
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: B20 tokens are precompiles with low bytecode, and genuine ones allow issuer freeze/burn. However, it lacks details like whether the tool returns a boolean or more info, and does not address side effects (none expected). Without annotations, this is adequate but not exhaustive.
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?
The description is detailed but longer than necessary. It front-loads the core question but includes explanatory asides ('As people learn...') that could be trimmed. Every sentence adds some value, but conciseness could be improved by focusing on the key distinction and behavior.
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?
Given no output schema and no annotations, the description should cover return value, error conditions, and usage context. It omits what the tool returns (likely a boolean or object) and does not relate to sibling tools. It explains the domain but leaves the agent uncertain about integration.
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?
The schema lists 'chain' and 'address', but the description provides no explanation of these parameters. With 0% schema description coverage, the description fails to add meaning to the parameters. It should clarify the role of 'chain' (e.g., which Base network) and the format of 'address'.
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 clearly states the tool's purpose: to check if a Base-native B20 asset is genuine or an ordinary ERC-20. It explains the distinction and implications. However, it does not differentiate from siblings directly, though sibling names like 'rug_powers' and 'vet_meme' suggest different verification focuses.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies it's for verifying B20 tokens, but siblings like 'vet_approach' or 'open_approvals' might also be relevant. Missing context on prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What key material is on this disk, and which of it is readable without a password? The companion to seed_exposure, and it exists because a real theft happened WITHOUT the phrase ever being written down: the key was exfiltrated. The trap is that a secp256k1 private key is 64 hex characters and so is every SHA-256 hash, every git object id and every transaction hash in a saved response — searching for the value SHAPE finds hashes by the thousand. Two things carry information instead: STRUCTURE (a Web3 Secret Storage keystore has version 3 and a crypto member with ciphertext, kdf and mac — nothing else looks like that, and finding one is not an exposure, it is an encrypted wallet whose strength is its password), and THE LABEL (cleartext keys are named by what needs them, so this matches PRIVATE_KEY and rejects PRIVATE_KEY_HASH). The finding people miss is RETAINED COPIES: rotating a secret does not remove it from the disk, because editor history, session caches and backup folders keep snapshots of what the file used to say — on the machine this was built for, one .env with three named keys had eighteen previous versions still readable. Also reports browser wallet vaults by PRESENCE only, since that is how a key leaves a machine when it was never in a text file. Never outputs key material, not even a prefix: a four-byte prefix narrows a brute force. Read-only, never decrypts, never derives an address.
| Name | Required | Description | Default |
|---|---|---|---|
| paths | No | directories to scan; defaults to Documents, Desktop and Downloads |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavioral traits: read-only, never outputs key material, never decrypts, explains what it detects (structure, label, retained copies, browser vaults) and what it avoids (false positives).
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?
The description is lengthy but each sentence provides necessary context for a sensitive security tool. Could be slightly more concise, but front-loaded with main purpose.
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?
For a complex tool with no output schema, the description covers all essential aspects: what it finds, common pitfalls, companion tool, read-only nature, and behavioral constraints.
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 covers 100% with clear parameter description. The description adds default behavior info but does not significantly enhance beyond the schema.
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 explicitly states the tool finds key material on disk, distinguishes readable vs encrypted keys, and warns about retained copies. It clearly distinguishes from sibling seed_exposure by explaining it's the companion for key exfiltration scenarios.
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?
Provides strong context on when to use (key exposure investigation) and references the companion tool seed_exposure. Does not explicitly list exclusions but the narrative implies appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who paid for this launch, and what else did they pay for? A token names its creator; a creator minted minutes ago names the wallet that funded it; and that funder usually funded others. Three free queries surface a cluster no buyer sees from a chart. Reports STRUCTURE, never intent — a shared paymaster proves shared control or shared infrastructure, and a launchpad is indistinguishable from a rug factory on the graph alone. What it does prove is that those tokens share fate.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | ||
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description partially discloses behavioral traits (e.g., 'Reports STRUCTURE, never intent', 'shared paymaster proves shared control or shared infrastructure'). However, it omits key details like auth needs, rate limits, or whether the tool is read-only.
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?
The description is verbose and not front-loaded. It opens with a rhetorical question and uses figurative language, making it inefficient for quick comprehension. Important operational details are buried or missing.
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?
Given 2 parameters, no output schema, and no annotations, the description is severely incomplete. It lacks information on return values, error handling, and operational nuances, making it insufficient for reliable tool use.
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?
The input schema has two parameters (chain and address) with 0% schema description coverage. The description does not explain what these parameters mean, expected formats, or valid values, leaving the agent without necessary guidance.
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 uses metaphorical language ('Who paid for this launch, and what else did they pay for?') but fails to clearly state the tool's action. It hints at tracing funders and clusters but is vague and not actionable for an agent.
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?
No explicit guidance on when to use launch_funder versus siblings like rug_powers or vet_meme. The poetic description does not provide context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which doors into this wallet are still open? An ERC-20 approval is a standing permission to move your tokens without asking again, and it is the most common drain vector that does NOT need the private key: approved once for an unlimited amount, months ago, forgotten. Wallets do not surface these. The load-bearing discipline is that an Approval EVENT IS NOT THE CURRENT STATE — a later approval of zero revokes an earlier one silently — so the log supplies candidate (token, spender) pairs and every one is confirmed by calling allowance() on the chain right now. Four outcomes, never two: live, confirmed-revoked, not-applicable (the call reverted, which is a definitive answer), and COULD-NOT-CHECK. The first draft collapsed the last two and reported forty closed doors having verified nine; an unanswered call is not a closed door. Read-only — it tells you what to revoke, and can never revoke or sign.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | base (default) | ethereum | |
| owner | Yes | the wallet address to audit |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses behavioral traits: it distinguishes four outcomes, confirms state via on-chain allowance() calls, emphasizes read-only nature, and warns about data interpretation (event vs state). No annotations exist, so the description bears full burden and meets it thoroughly.
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?
The description is longer than necessary, including background on ERC-20 approvals that may not be essential. It is front-loaded with a metaphor, but subsequent details could be more compact. Adequate but not optimally concise.
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?
For a tool with no output schema, the description adequately explains the four outcome states and the on-chain verification method. It lacks explicit detail on the return format (e.g., JSON structure), but covers the essential behavioral context. Missing minor details hold it back from a perfect score.
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% (both parameters documented). The tool description adds no additional parameter meaning beyond the schema's brief descriptions, meeting the baseline for high coverage but not enhancing it.
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 clearly states the tool's function: auditing ERC-20 approvals for a wallet, reporting four distinct statuses. It uses a vivid metaphor ('which doors are open') and explicitly distinguishes itself from tools that might revoke or sign, indicating read-only behavior.
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?
No explicit guidance on when to use this tool versus alternatives (e.g., other audit tools). The description explains the importance of approvals but does not compare to sibling tools or specify use cases where this tool is most appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Judge an offer to recover already-stolen funds. Answerable with certainty rather than a score, because the ask is the tell: recovery happens through the thief, a court, an exchange, or an issuer — never through the victim's wallet. A recovery needing your signature or an upfront fee is not merely suspect, it is structurally impossible as described, however credible the person sounds and however accurately they recite your loss (the theft is public; anyone can read it back to you). Never returns "safe".
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | ||
| address | No | the address you were asked to pay (optional — its absence is not reassurance) | |
| asksToInstall | No | ||
| asksForSeedOrKey | No | ||
| asksForSignature | No | ||
| asksForUpfrontPayment | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the deterministic behavior ('Answerable with certainty'), the never-returns-safe result, and the reasoning process about legitimate recovery channels. This is strong transparency, though it does not cover all parameter behaviors.
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?
The description is a coherent paragraph of about 5 sentences, efficiently conveying key concepts. It is well-structured and front-loaded, but contains some complex sentences that could be simplified. Still among the better examples.
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?
Given no output schema and sparse schema descriptions, the description effectively covers the tool's purpose, logic, and expected results. It adequately informs an agent about what the tool does and how to interpret its output, though it lacks a detailed return format explanation.
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 coverage is only 17% (only 'address' described). The description adds meaning by explaining why parameters like 'asksForSignature' and 'asksForUpfrontPayment' are critical, but does not explicitly describe each parameter or their types. It partially compensates for low coverage.
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 clearly states the tool judges recovery offers for stolen funds, using the specific verb 'judge' and resource 'offer to recover already-stolen funds'. It distinguishes from sibling tools like 'trace_theft' by focusing on offers rather than tracking, providing a unique purpose.
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?
The description implicitly tells when to use by describing the nature of recovery offers, but does not explicitly state 'use this when you receive a recovery request' or contrast with other tools. It lacks direct usage guidance or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given the contract, what powers does its deployer still hold over your money? The load-bearing idea, and why flag-listing scanners are noise: a dangerous capability only counts if someone can still FIRE it. Mintable with ownership renounced is inert; the same flag with a live owner is an armed rug. Merges a curated index (owner powers, LP locks) with a live trade simulation, because the index has never heard of a token minted ten minutes ago and the simulation cannot see who is in control. Never returns clean on simulation alone.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | base (default) | ethereum | bsc | polygon | arbitrum | optimism | avalanche | |
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description effectively discloses key behavioral traits: it merges a curated index with live trade simulation, explains that dangerous capabilities only count if someone can fire them, and states it never returns clean on simulation alone. This provides good transparency beyond schema.
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?
The description is moderately lengthy with multiple sentences, some of which are explanatory but not strictly necessary (e.g., analogy about scanners). It is structured with the main purpose front-loaded, but could be trimmed for efficiency.
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?
Given the tool's complexity and lack of output schema, the description does not explain return values or format. It mentions 'never returns clean on simulation alone' but is vague. For a tool assessing powers, the output structure is critical and 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 coverage is 50% (only 'chain' has description). The description does not add meaning beyond the schema for either parameter; it only indirectly references the address as 'the contract'. No additional guidance on format or constraints is given.
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 clearly states the tool assesses what powers the deployer still holds over user funds, using specific verbs and resource. It distinguishes from sibling tools like 'vet_meme' by focusing on deployer powers and real-time risk evaluation.
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?
The description implies usage for evaluating deployer powers but does not explicitly state when not to use it or provide alternatives among siblings. It gives context about merging index and simulation but lacks clear guidance on when to choose this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Is a recovery phrase sitting in cleartext on this machine? "Self custody if you know how to keep your seedphrase safe" puts the whole condition in the sentence, and nothing ships that checks it: an antivirus answers "do you have a known virus", not "is my seed readable by anything that runs here". This question is DECIDABLE rather than scored, which is why it is worth answering. A keyword scan drowns — abandon, able, about and absent are ordinary English and all four are BIP-39 words — but a mnemonic is a RUN of 12/15/18/21/24 consecutive words from a 2048-word list, and BIP-39 puts a CHECKSUM in the last word, so a candidate is proven by arithmetic. It NEVER outputs the phrase: only the file, the line and the word count, because this output ends up in terminal buffers, logs and screenshots, and a scanner that prints the seed it found is a stealer with good intentions. Reports its own blind spots: it cannot read images, PDFs, password managers, browser storage or encrypted archives, so "nothing found" means nothing was found IN WHAT WAS READ. Read-only, no network, zero dependencies.
| Name | Required | Description | Default |
|---|---|---|---|
| paths | No | directories to scan; defaults to Documents, Desktop, Downloads and OneDrive equivalents |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description explicitly states read-only, no network, zero dependencies, that it never outputs the phrase, only file/line/word count, and lists its blind spots. This fully compensates for missing annotations.
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?
The description is verbose (multiple sentences) and includes slightly tangential remarks (e.g., 'Self custody if you know how...'). While informative, it could be more concise while retaining key points.
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?
Given no output schema, the description fully explains output format (file, line, word count) and what is not output (the phrase). It also covers limitations (blind spots) and safety claims, making it complete for an agent to use correctly.
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 coverage is 100% for the single parameter 'paths', and its description already includes default directories. The tool description adds general scanning behavior but does not provide additional semantics for the parameter beyond what the schema offers.
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 clearly states the tool's purpose: checking if a BIP-39 recovery phrase is in cleartext on the machine. It distinguishes from keyword scans and explains the decidable approach using BIP-39 word list and checksum, making it specific and actionable.
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?
The description provides context on when to use this tool (to check for cleartext seed phrases) and lists blind spots (images, PDFs, etc.), but does not explicitly contrast with sibling tools like key_exposure or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Follow stolen funds from the victim's transaction to where the trail dies. moved: what actually left a wallet, marking which transfers are authentic — ERC-20 Transfer logs are attacker-controlled text, so only the transaction signer is authoritative. bridge: read a cross-chain exit; aggregators write the destination into their own calldata because the far side needs it, and chain ids are checked against a table before any field is called an amount. tron: walk a TRON account, detecting relay hops — an account forwarding what it received, within seconds, is a pass-through and not a destination.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | moved | bridge | tron | |
| chain | No | ||
| txHash | No | ||
| address | No | TRON T-address for mode tron | |
| maxHops | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides significant behavioral details beyond what annotations (none) offer, such as explaining that ERC-20 Transfer logs are attacker-controlled, bridge aggregators write destination into calldata, and TRON accounts are analyzed for relay hops. These insights help the agent understand limitations and inner workings, though side effects or destructive actions are not mentioned.
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?
The description is front-loaded with a clear purpose sentence but becomes dense and technical in the following sections. Each mode is explained, but the overall length and complexity reduce conciseness. Some sentences are run-on, making the structure less efficient.
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?
Given the tool's complexity (5 parameters, no output schema, technical domain), the description is incomplete. It thoroughly explains mode behavior but omits details about other parameters, return values, error conditions, or example usage. The lack of output schema increases the need for description completeness, which is not met.
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?
With schema coverage at 40%, the description must compensate for undocumented parameters. It effectively explains the 'mode' parameter's three values (moved, bridge, tron), but fails to describe the remaining parameters (chain, txHash, maxHops) beyond their names. This leaves significant gaps in understanding their formats and roles.
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 tool description clearly states 'Follow stolen funds from the victim's transaction to where the trail dies,' establishing a specific verb (follow) and resource (stolen funds). The description distinguishes this tool from siblings by focusing on theft tracing, which contrasts with other sibling tools like 'vet_meme' or 'rug_powers' that serve different investigative purposes.
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?
The description implicitly guides usage by detailing three modes (moved, bridge, tron) and their contexts, but it lacks explicit guidance on when to use this tool versus alternatives, when not to use it, or prerequisites. The usage is implied rather than stated outright.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Is this agent safe to connect to, and safe to pay? Four checkable dangers, none needing trust in a description. It does not exist — a listing is not a service, and paying an endpoint that never answers is the simplest loss available. Its tools can move money — a name is marketing, the input SCHEMA is the capability, and only a QUANTITY field proves a payment surface, because a message has a recipient exactly as a payment does but you cannot move value without saying how much. It asks for key material — a schema field for a private key or seed is the whole attack, declared in the open. Or it is paid to an address with no past. HTTP 401/403 returns unauditable rather than unreachable: the agent is running and gated, which is neither a pass nor a fail. Deliberately does NOT grade how good the description reads, because a well-written tool listing is free to fabricate and scoring prose would hand a forgery a good mark. Introspects and never calls a tool.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | the agent's HTTP MCP endpoint | |
| chain | No | base (default) | |
| payTo | No | optional: the address that would receive payment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is highly transparent about behaviors: it introspects and never calls a tool, it checks four specific dangers (nonexistent agent, money-moving tools without quantity, key material requests, payment to address with no history), and it returns 'unauditable' for 401/403. This fully compensates for the lack of annotations.
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?
The description is verbose and discursive, containing philosophical asides and meta-commentary (e.g., 'Deliberately does NOT grade how good the description reads'). It could be more concise while retaining the key points. The structure is a single paragraph rather than a clear list, reducing readability.
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?
Given the tool's complexity (vetting an agent with no output schema), the description explains the approach well but lacks specification of the return value. It mentions 'unauditable' for HTTP errors but does not describe the normal output format (e.g., boolean, risk score). This gap leaves the agent uncertain about the tool's output.
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?
The schema already describes the three parameters (url, chain, payTo) with 100% coverage. The description adds significant context beyond the schema, explaining how it interprets these parameters during vetting (e.g., checking for a QUANTITY field in tools, or a private key field). This enrichment justifies a score above baseline 3.
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 clearly states the tool's purpose: to check if an agent is safe to connect to and pay. It explicitly lists four dangers it checks and distinguishes itself from siblings like 'vet_meme' and 'vet_approach' by focusing on safety and introspection, never calling a tool.
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?
The description implies usage (vet an agent before connecting/paying) but does not explicitly state when to use this tool vs alternatives. No exclusions or when-not-to-use guidance is provided, though the context of checking dangers is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Judge an inbound opportunity — podcast, interview, partnership, job, AMA — by what it ASKS, not by how good it looks. Built from a lure that worked on someone who verifies counterparties professionally: a 35-question production dossier citing his real work, using his own catchphrase, quoting his posts, and asking genuinely hard questions, because a flatterer never includes criticism and including it is what makes an approach read as journalism. The mechanism is effort as a trust signal: that much detail used to cost hours of human work, so nobody spent it on one target. That arithmetic no longer holds. So this does NOT score how convincing an approach is — that would give a forgery a good grade. It grades where a link actually points (a brand to the left of the registrable domain is a free label: wechat.web09eu.com is web09eu.com) and what the sender wants from you. Never returns safe.
| Name | Required | Description | Default |
|---|---|---|---|
| links | No | ||
| urgency | No | ||
| platform | No | ||
| asksToInstall | No | ||
| asksForKeyOrSeed | No | ||
| asksForSignature | No | ||
| asksForUpfrontPayment | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors. It mentions it grades links and sender wants, and does not score persuasiveness, but fails to explain output format, side effects, or limitations like what 'Never returns safe' means.
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?
The description is overly verbose and reads like a story, burying key functional details. It is not concise and wastes sentences on narrative rather than clear specification.
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?
Given 7 parameters, no output schema, and no annotations, the description is severely incomplete. It does not adequately describe inputs, outputs, or behavior for an AI agent to use the tool correctly.
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 0%, and the description only loosely hints at parameters like 'links' and 'asksToInstall'. It does not explain individual parameters, their types, or how they influence behavior.
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 it judges inbound opportunities by what they ask, and grades links and sender wants, but the purpose is buried in a lengthy narrative. It is vague and not immediately clear what the tool does.
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?
No explicit guidance on when to use this tool versus its siblings. The description only says 'Never returns safe' but provides no context for appropriate usage or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which contract is the REAL token behind a ticker? A meme symbol routinely has ten or more look-alike contracts across chains, and buying the wrong one is a total loss. Fail-closed from live liquidity: genuine (one contract dominates), ambiguous (top two tied — NEVER certified), impersonation (the address you passed is not the dominant one), thin (nothing credible).
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| address | No | optional: judge THIS specific contract | |
| chainId | No | optional: restrict to one chain, e.g. base |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the tool's behavior: it checks live liquidity and returns one of four outcomes (genuine, ambiguous, impersonation, thin). The term 'fail-closed' indicates a safety orientation. However, it does not explicitly state whether the tool is read-only or if it has any side effects.
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?
The description is very concise, using just three sentences to convey purpose, context, and possible outcomes. It is front-loaded with a clear question and effectively uses line breaks for readability.
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?
Given the complexity of the tool (identifying real contracts among look-alikes) and the lack of an output schema, the description provides sufficient context: it explains the problem and lists the four possible outcomes. It covers the key aspects an agent needs to understand what the tool does and what results to expect.
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?
The input schema describes three parameters with partial descriptions (67% coverage). The description adds context by mentioning 'the address you passed', but does not explain how the parameters interact with the logic or provide additional details beyond the schema.
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 clearly states the tool's purpose: to identify the real token contract behind a meme ticker among many look-alikes. It uses a specific verb ('vet') and resource ('meme token contracts'), and distinguishes itself from sibling tools by focusing on meme tokens with multiple look-alike contracts.
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?
The description strongly implies when to use the tool: when dealing with meme symbols that have many look-alike contracts. It also hints at the risks ('buying the wrong one is a total loss'). However, it does not explicitly state when not to use this tool or mention alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What CHANGED around this wallet since we last looked? The other tools answer at a point in time; this one remembers, which is what turns them into a guard. Three unlimited approvals granted last year are a standing condition; a fourth appearing this morning is an event, and only the second deserves to interrupt anyone — a monitor that repeats its standing conditions teaches its reader to close it, and a closed monitor is worth nothing. Detects new live allowances and first-time counterparties, then JUDGES each one against a local known-bad screen and the explorer rather than merely announcing it. Uses transactions, not event logs, because an ERC-20 Transfer log names whoever the emitting contract chose. Reports its own blind spots every run: on a wallet monitor an empty alert list reads as "you are safe". First run is an inventory, not a set of events.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | base (default) | ethereum | |
| owner | Yes | the wallet address to watch | |
| persist | No | default true — save state so the NEXT call can diff against it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses key behaviors: detects new allowances and counterparties, judges against known-bad screens, uses transactions not logs, reports blind spots, and describes persistence effect.
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?
Description is overly verbose and metaphorical, with flowery language that obscures clarity. Could be significantly condensed without losing meaning.
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?
Given 11 sibling tools and no output schema, the description thoroughly explains behavior, differentiation, and edge cases (first run, blind spots). Complete for its complexity.
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 covers all 3 parameters with descriptions (100% coverage). Description adds minimal extra context (e.g., effect of persist). Baseline 3 is appropriate.
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?
Clearly states the tool watches for changes around a wallet since last check, distinguishing it from siblings that only answer at a point in time. The verb 'watch' and resource 'wallet' are explicit.
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?
Implies usage for monitoring changes over time, contrasts with point-in-time tools. Notes first run is an inventory. However, lacks explicit when-not-to-use or alternative tool names.
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. Dates show when Glama detected each change.
v0.1.0b20_authentickey_exposurelaunch_funderopen_approvalsrecovery_offerrug_powersseed_exposuretrace_theftvet_agentvet_approachvet_memewatch_walletEach tool addresses a distinct security concern or forensic task, from contract powers to meme token verification, theft tracing, scam detection, approval checks, wallet monitoring, agent vetting, and local key scanning. There is no overlap in purpose.
Most tool names follow a verb_noun pattern with underscores (e.g., rug_powers, vet_meme, trace_theft), though some are noun_noun (seed_exposure, key_exposure) and one starts with a code (b20_authentic). The naming is clear and descriptive but shows minor inconsistency in pattern.
12 tools is well-scoped for an on-chain forensics server. Each tool covers a specific area without redundancy, and the set feels comprehensive yet manageable for an agent.
The tool set covers a broad range of on-chain and local security checks, including contract analysis, token verification, fund tracing, scam detection, wallet monitoring, and key identification. Minor gaps might include lack of NFT-specific tools or integrated reporting, but the overall coverage is strong.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Rug pull risk and on-chain forensics for tokens on Solana, Ethereum, Base and Robinhood.
Read-only crypto safety: token honeypot checks, EIP-712 signature decode, approval scans.
Instant rug-check for any EVM or Solana token, distilled to one clear 0-10 risk verdict.
Pre-transaction risk screening for Ethereum addresses: signed score, sanctions, audit trail.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/philpof102-svg/onchain-forensics'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
