Dechonet-MCP

Check Before Signing or Sending (Crypto)

crypto_check_before_sign

Read-onlyIdempotent

Before an agent signs or sends from a crypto wallet: send the destination address (to), the page that asked (url) and/or the wallet request it is about to approve (request: the EIP-1193 method and params). The address is checked for its chain and checksum, the US Treasury OFAC sanctions list, and pages DechoNet judged dangerous that showed it; the page goes through the phishing link check and the official exchange, wallet and dApp list; the request is read for what approving it would allow (unlimited token approval, approval for a whole NFT collection, Permit/Permit2 signatures, Seaport orders, raw eth_sign, transfers). Verdicts: danger, suspicious, no_signals. no_signals means none of the checks found a warning sign and is not a statement that the transaction is harmless; 'unchecked' lists what was not looked at (balances, token contracts, simulation). Nothing sent is stored. Rate-limited.

Input Schema

Name	Required	Description
`to`	No	Destination wallet address (0x…, T…, bc1…, Solana)
`url`	No	Address of the page that asked for the signature or transfer (https://…)
`request`	No	The wallet request about to be approved

Output Schema

Name	Required	Description
`request`	No	What approving the request would allow
`signals`	Yes
`verdict`	Yes	danger: a check found a danger sign; suspicious: a warning sign; no_signals: none of the checks found one — not a statement that the transaction is harmless (see unchecked)
`receipts`	No	Signed observation receipts behind this result, one per lookup: when, from where and under which rules version DechoNet observed it. Each url shows the record and checks its Ed25519 signature.
`unchecked`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations, it discloses the specific checks performed, the possible verdicts, the crucial meaning of no_signals, what unchecked means, that nothing sent is stored, and that the tool is rate-limited. These details materially help an agent interpret and trust the result.

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

Conciseness4/5

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

The description is front-loaded with the pre-signing purpose and remains information-dense rather than padded. It is somewhat long and runs multiple check categories together, but the length is largely justified by the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, the description need not explain return structure in detail. It still covers the verdict model, unchecked scope, storage behavior, and rate limiting, which makes it complete enough for an agent to call and interpret the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents the parameters. The description adds useful semantics by explaining the roles of to, url, and request, and by indicating they can be supplied in combination with 'and/or' even though none are marked required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific pre-signing/pre-send crypto safety check and enumerates the exact resources checked: destination address, requesting page, and EIP-1193 wallet request. It clearly distinguishes this from a generic address lookup by covering address, page, and transaction-approval risks together.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear trigger: use this before an agent signs or sends from a crypto wallet. It does not explicitly name alternatives such as wallet_address_check or phishing_link_check, but the pre-signing context and verdict semantics make the intended usage clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Dechonet-MCP tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?