Dechonet MCP

Check Before Signing or Sending (Crypto)

crypto_check_before_sign

Read-onlyIdempotent

Checks a crypto destination address, requesting page, and wallet request for sanctions, phishing, and dangerous approvals before an agent signs or sends; returns danger, suspicious, or no_signals.

Instructions

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, the addresses the FBI published in its alerts, 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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "crypto_check_before_sign"
  }
}

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.

Addedv1.7.0Oct 31, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnly/destructive annotations the description adds material behavior: the exact data sources consulted (OFAC, FBI-published addresses, DechoNet dangerous pages, exchange/wallet/dApp list), the three verdict values with an explicit warning that no_signals is not a safety guarantee, the 'unchecked' bucket (balances, token contracts, simulation), the no-storage policy, and rate limiting. That is far more than the annotations convey.

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?

Front-loaded with the when-to-call, then the inputs, then what is checked, then the verdict semantics — a logical order. The single dense semicolon-chained block is efficient but would scan faster as short lines, and a phrase like 'the page that asked (url)' borders on restating the schema.

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?

For a read-only, open-world checker with an output schema, this covers everything an agent needs to call it correctly: required inputs, the meaning of each verdict, the explicit non-guarantee of no_signals, the scope limits ('unchecked'), and side effects (no storage, rate limit). Return-value structure is correctly left to the output schema.

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 baseline would be 3, but the description maps each parameter to a distinct verification path (address → chain/checksum/sanctions; url → phishing and allow-list; request → what the approval would grant). It adds no format examples beyond the schema and does not address what happens when zero optional parameters are supplied.

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 names a specific verb and object ('check before an agent signs or sends from a crypto wallet') and enumerates exactly what gets inspected: the destination address, the page that requested it, and the EIP-1193 request. It is clearly distinguishable from siblings like phishing_link_check, wallet_address_check, or check_before_action because it composes all three checks into one pre-signature verdict.

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?

The trigger condition is explicit and front-loaded: call this before signing or sending, supplying 'to', 'url' and/or 'request'. It does not name alternatives or state when NOT to use it (e.g. when only the destination address matters, use wallet_address_check instead), so routing among the many sibling security tools is left partly to inference.

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