Click on "Deploy 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., "@calldata-guardian decode 0x095ea7b3... on ethereum"
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.
Know what you're signing — before you sign it.
calldata-guardian is an MCP server and a pay-per-call x402 HTTP API. Give it a transaction's chain + to + data (calldata) + value and it returns a SAFE / REVIEW / DANGER verdict with a plain-English list of exactly what the transaction will do — flagging the dangerous things a wallet should never sign blindly.
⚠️ Read-only decode/safety screen, not a guarantee. calldata-guardian never holds a key and never broadcasts anything. It cannot decode every custom selector. Never sign a transaction you do not understand.
A wallet/agent that "just looks at the calldata" still can't tell you the things that matter:
Decode the 4-byte selector into arguments — turn 0x095ea7b3…ffff… into "approve UNLIMITED to 0xDEAD".
Live on-chain context the calldata alone doesn't carry — is to a contract at all? is it an EIP-1967 upgradeable proxy whose logic can be swapped after you sign? is the approved spender/operator a known router or a random EOA (the classic phishing pattern)?
Token metadata — resolve decimals/symbol so 1.157e59 is shown as UNLIMITED.
calldata-guardian batches all of that and returns one verdict with the human "this will…" breakdown.
Related MCP server: chain-signer
♾️ Unlimited approval |
|
✉️ Gasless permit | EIP-2612 |
🃏 setApprovalForAll | hands an operator control of ALL your NFTs in a collection |
💸 Drains |
|
👻 EOA spender | an approval where the spender is a plain wallet — a classic phishing pattern |
🔗 Upgradeable / non-contract target |
|
{
"mcpServers": {
"calldata-guardian": { "command": "npx", "args": ["-y", "calldata-guardian-mcp"] }
}
}Tools:
preview_transaction — full decode + risk verdict. Params: chain, to, data, value.
decode_calldata — quick "what function is this?" decode. Params: to, data, chain.
Or connect over HTTP at POST /mcp.
GET /preview?chain=ethereum&to=0xTOKEN&data=0x095ea7b3...Returns the decoded actions, signals, and a SAFE/REVIEW/DANGER verdict.
The /pro/preview route is gated by x402. Your agent pays $0.15 USDC per call automatically — no sign-up, no API key. Settles on-chain (Base) to the operator wallet.
GET /pro/preview?chain=base&to=0x...&data=0x... # 402 → pay → full decodeEthereum · Base · BSC · Polygon · Arbitrum — all via public, key-free RPCs.
npm-guardian · contract-auditor · rug-check · approval-guardian · calldata-guardian
Source & docs: github.com/Baneado98/calldata-guardian · MIT
Decode a single piece of EVM calldata (the 4-byte selector + arguments) into its function and parameters. For full risk context (is the spender an EOA? is to a proxy?), use preview_transaction instead. Returns the function name and decoded args for the known supply-chain-relevant selectors (approve, permit, setApprovalForAll, transfer, transferFrom, increaseAllowance, transferOwnership, multicall).
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain used to resolve token metadata (default ethereum). | |
| to | Yes | The target contract address (0x...). | |
| data | Yes | The calldata to decode (0x...). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It mentions that decoding works for known supply-chain-relevant selectors, implying limitations. However, it does not disclose error handling, whether it validates calldata, or if it is state-changing (assumed read-only). Adequate but could be more specific.
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?
Two sentences, front-loaded with verb+resource, no fluff. Each sentence earns its place.
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?
No output schema, but description specifies return (function name, decoded args) and lists selectors. Adequate for the tool's simplicity, though could mention return format.
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% so baseline is 3. Description adds value by explaining purpose and listing known selectors, but does not provide additional details beyond schema for the three parameters.
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?
Description clearly states the tool decodes EVM calldata into function name and parameters, specifying verb (decode), resource (calldata), and output. It distinguishes from sibling preview_transaction by noting risk context.
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?
Explicitly tells when to use this tool (decoding calldata) and when to use the sibling (preview_transaction for risk context). Provides clear guidance on selecting between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode and explain an EVM transaction BEFORE signing it — the 'what am I about to sign?' check. Give it a chain + the transaction's to / data (calldata) / value and it returns a SAFE / REVIEW / DANGER verdict with a plain-English list of exactly what the transaction will do, flagging the dangerous things a wallet should never sign blindly: unlimited token approvals, EIP-2612 / Permit2 gasless permits, setApprovalForAll on NFTs, transferFrom drains, increaseAllowance top-ups, ownership transfers, multicall bundles that hide an approval, and calls to non-contract / upgradeable targets or approvals to a plain-wallet (EOA) spender. It also reads live on-chain context (is to a contract / proxy? is the spender an EOA?) and resolves token decimals so amounts are human-readable. Read-only; never signs or broadcasts. Use this whenever an agent is about to sign or relay a transaction it didn't fully construct. Chains: ethereum, base, bsc, polygon, arbitrum.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | Chain: ethereum, base, bsc, polygon or arbitrum. | |
| to | Yes | The transaction's `to` address (contract or recipient, 0x...). | |
| data | No | The calldata (0x...). Optional for a pure value transfer. | |
| value | No | Native value in wei (decimal or 0x). Optional, default 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explicitly states it is read-only, never signs or broadcasts, and describes what it checks (dangerous patterns) and returns (verdict + human-readable list). It also mentions live on-chain context reading.
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 single coherent paragraph that starts with main purpose, then details checks, and ends with usage guidance. It is informative but slightly long; however, every sentence adds value and is well-structured.
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?
No output schema exists, so description must explain return values. It does so by stating it returns a SAFE/REVIEW/DANGER verdict with a plain-English list. It covers all necessary aspects for an agent to decide when to call this tool.
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%, baseline 3. The description adds meaning beyond schema: lists supported chains for the chain parameter, explains to as contract/recipient, data as calldata (optional for pure transfer), and value in wei. This enhances understanding.
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 decodes and explains an EVM transaction before signing, returning a verdict with plain-English list. It specifies inputs (chain, to, data, value) and distinguishes from sibling decode_calldata by focusing on pre-signing safety analysis.
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 explicitly says 'Use this whenever an agent is about to sign or relay a transaction it didn't fully construct.' This provides clear when-to-use guidance, though it does not explicitly state when not to use or compare with siblings.
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.
v0.1.0decode_calldatapreview_transactionScored across 2 tools
The two tools serve distinctly different purposes: decode_calldata provides basic parameter decoding, while preview_transaction offers a comprehensive risk assessment with live context. The descriptions clearly differentiate them, leaving no ambiguity.
Both tools use a consistent verb_noun pattern with snake_case (decode_calldata and preview_transaction), adhering to a predictable naming convention.
With only 2 tools, the set is slightly thin, but it covers the core functionality of calldata decoding and transaction preview without unnecessary bloat, making it appropriate for its focused scope.
The tool set covers the essential operations: basic decoding for known selectors and a full transaction preview with risk assessment and live on-chain context. There are no obvious gaps for the stated purpose of a calldata guardian.
Read-only crypto safety: token honeypot checks, EIP-712 signature decode, approval scans.
Decode any Base tx: plain English, strict JSON, risk flags, no LLM. 50 free/day per IP, then $0.02.
Decode EVM bytes to JSON: event-log decoder, calldata explainer, selector lookup, ABI fetch.
Pre-transaction health and safety verdicts for onchain apps, by contract address.
