Prototyp · Vorschau: alle Server aus der offiziellen Registry, alle 30 Minuten synchronisiert. Bewertungen und Benutzerkonten folgen in einem späteren Schritt.
PopNx MCPMCP-Server für alle, die KI nutzen · in einfachen Worten erklärt

Chain Signer

von Kevthetech143Version 0.5.31i★ –iLäuft auf deinem Computer
Name in der Registryio.github.Kevthetech143/chain-signer

Installieren

Überblick

Beschreibung vom Entwickler (englisches Original)

Security suite for AI agents: flag drains, permit-phishing & risky actions before signing.

Die drei Säulen von PopNx MCP

Diese drei werden nie zu einer Punktzahl zusammengefasst: Meinungen, Messungen und Beliebtheit sind verschiedene Dinge.

Was du damit machen kannst

Für diesen Server haben wir noch keine Zusammenfassung in einfacher Sprache geschrieben. Unten stehen die Fakten, die wir aus der Registry gelesen haben.

  • Verbindung: Läuft auf deinem Computer
  • Transport: stdio
  • Kategorie: Cybersicherheit

Installation

Wähle die KI-App, die du nutzt, und kopiere die Einstellungen.

Bevor du installierst

  • Basischecks: 1 von 1 bestanden
  • Läuft auf deinem Computer mit den Rechten deines Benutzerkontos (Dateien, Netzwerk, Apps).
  • Die Registry nennt keinen Schlüssel zum Eintragen.

Du brauchst

  • PyPIuv für Python installiert (für den Befehl uvx)

Welche App nutzt du?

Wähle oben deine App. Wir merken sie uns, damit der Button beim nächsten Mal „In … installieren“ anzeigt.

Öffne Claude Desktop → Settings → Developer → Edit Config und füge dies in claude_desktop_config.json ein

{
  "mcpServers": {
    "chain-signer": {
      "command": "uvx",
      "args": [
        "chain-signer"
      ]
    }
  }
}

Führe das in deinem Terminal aus

claude mcp add chain-signer -- uvx chain-signer

In Cursor öffnen

Oder kopier die Einstellungen selbst

In .cursor/mcp.json in deinem Projekt oder in ~/.cursor/mcp.json einfügen

{
  "mcpServers": {
    "chain-signer": {
      "command": "uvx",
      "args": [
        "chain-signer"
      ]
    }
  }
}

Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.

In VS Code öffnen

Oder kopier die Einstellungen selbst

In .vscode/mcp.json in deinem Projekt einfügen

{
  "servers": {
    "chain-signer": {
      "type": "stdio",
      "command": "uvx",
      "args": [
        "chain-signer"
      ]
    }
  }
}

Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.

Dieser Server läuft auf deinem Computer, und ChatGPT kann sich nur mit Servern im Internet verbinden. Wähle eine andere App.

Deine Auswahl bleibt in einem Cookie auf diesem Gerät; kein Konto nötig.

Diese Einstellungen werden aus dem Registry-Eintrag des Entwicklers erzeugt. Wenn in der README etwas anderes steht, folge der README.

Was er kann

Läuft auf deinem Computer; die Tool-Liste erscheint nach der Installation in deiner KI-App.

Basischecksi

Wir prüfen Informationen, die jeder sehen kann; den Code haben wir nicht gelesen. Checks, die nicht zutreffen, werden nicht mitgezählt. · Geprüft am 8. Nov. 2026

  • ✓ Bestanden

    Entwickler passt zum Repo

    Der Registry-Name wurde mit dem GitHub-Konto Kevthetech143 bestätigt, dem das Repo gehört

  • … Noch nicht geprüft

    Wird noch gepflegt

    Dieses Repo haben wir noch nicht von GitHub gelesen

  • … Noch nicht geprüft

    Hat eine Lizenz

    Dieses Repo haben wir noch nicht von GitHub gelesen

  • – Nicht zutreffend

    Endpunkt antwortet

    Dieser Server läuft auf deinem Computer; es gibt keinen Endpunkt im Internet

  • – Nicht zutreffend

    Anmeldung mit OAuth

    Läuft auf deinem Computer und nutzt stattdessen lokale Einstellungen

  • … Noch nicht geprüft

    Keine versteckten Anweisungen in Tool-Beschreibungen

    Läuft auf deinem Computer; Tool-Listen können wir nur von Endpunkten im Internet lesen

Im Vergleich mit anderen in Cybersicherheiti

  • Mehr Sterne als 0 % der anderen 997 Server in dieser Kategorie
  • Neuer in der Registry veröffentlicht als 21 % der anderen 997 Server in dieser Kategorie
  • Basischecks gleich gut wie oder besser als bei 100 % der anderen 997 Server in dieser Kategorie

Verglichen mit allen aktiven Servern dieser Kategorie in der Registry. Sterne zählen nur, wenn dem Herausgeber das Repo gehört.

Häufige Fragen

Ist Chain Signer sicher?

Er hat 1 von 1 zutreffenden Basischecks bestanden. Den Code haben wir nicht gelesen. Bevor du einen Schlüssel oder Token hinzufügst, sieh nach, welche Zugriffe der Server verlangt, und nutze einen Schlüssel, der nur die Berechtigungen hat, die du brauchst.

Welche Schlüssel oder Codes braucht er?

Die Registry nennt keinen erforderlichen Schlüssel, manche Server bitten dich aber bei der ersten Nutzung, dich anzumelden.

Läuft er auf meinem Computer oder in der Cloud?

Er läuft auf deinem Computer. Deine KI-App startet ihn bei Bedarf, und die Daten laufen nicht über die Server des Entwicklers (außer der Server ruft selbst einen Onlinedienst auf).

Wird er noch gepflegt?

Das GitHub-Repo wurde zuletzt – geändert, und die neueste Version (0.5.31) kam vor 5 Monaten in die Registry.

Welche Apps können ihn nutzen?

Apps, die MCP unterstützen, etwa Claude Desktop, Claude Code, Cursor und VS Code. Außerdem brauchst du Python (uv) auf deinem Computer.

Was kann ich stattdessen nutzen?

In derselben Kategorie: LucidShark, Threatist, Draugr

Alternativen

Server derselben Kategorie von anderen Entwicklern, sortiert nach Sternen.

So liest du eine Karte:★ GitHub-SterneiDrei Säulen: Bewertungen · Checks · NutzungiAktualisiert = neueste Version in der Registry veröffentlichti

LucidShark

von toniantunovi

Local code quality and security scanner: lint, types, SAST, SCA, tests, coverage.

Läuft auf deinem ComputerAktualisiert heute
Installieren

Threatist

von threatist.io

Vulnerability records: CVE, GHSA, CISA KEV, EPSS and vendor fixes in one place. No key needed.

Läuft in der CloudAktualisiert heute
Installieren

Draugr

von draugr-dev

Security scanning for AI agents: SAST, SCA, secrets, IaC, DAST, ranked by real risk.

Läuft auf deinem ComputerAktualisiert heute
Installieren

README vom Entwickler

README öffnen

Unverändert aus dem Repo des Entwicklers übernommen. PopNx MCP hat den Inhalt weder geprüft noch empfiehlt es ihn. HTML, Bilder und Skripte wurden entfernt. Links führen von dieser Website weg.

chain-signer

A security suite for AI agents — the seatbelt that catches the dangerous thing BEFORE it happens. Three guards, each callable on its own (and as MCP tools), pairing with any wallet or identity stack:

  • preflight(tx) — decode an unsigned transaction and flag drains before signing (unlimited/large approval, approve-all, token & NFT transferFrom, proxy upgrade, on-chain permit, on-chain Permit2 approve/permit/transferFrom, approvals hidden in multicall incl. Uniswap router batches and Multicall3 aggregate/aggregate3/aggregate3Value (the batch helper on every EVM chain), approvals wrapped in ERC-4337/smart-account execute/executeBatch, Gnosis Safe multiSend/execTransaction and DSProxy execute, drains routed through the Uniswap Universal Router (Permit2 permit/transferFrom commands incl. sub-plans), 1inch AggregationRouter v5 swap() with redirected output or zero slippage, 0x ExchangeProxy transformERC20() with zero slippage, EIP-7702 account delegation, will-revert).
  • inspect_typed_data(td) — catch permit-phishing in an EIP-712 message before the agent signs it (ERC-2612, Uniswap Permit2 incl. SignatureTransfer + witness variants, DAI-style permits) and Seaport orders that give assets away — zero consideration, proceeds routed to a third party, or hidden in a BulkOrder tree.
  • check_action(action, policy) — enforce allow/forbid + value/recipient limits before the agent acts.

All three fail safe and are guards, not guarantees. Also bundled: a non-custodial multi-chain wallet (burner, balance, send, swap) — the agent holds its own key and signs locally. No MetaMask, no account, no custody.

from chain_signer import assert_safe

assert_safe(tx) # raises if the tx is a drain/unlimited-approval/revert — review before signing

Install

pip install chain-signer

export ETHERSCAN_API_KEY=... # for live balance reads + broadcast (Etherscan v2)

Bitcoin/Solana support is optional: `pip install "chain-signer[all]"`.

Quickstart (10 seconds — offline, no key, no funds, no network)

pip install chain-signer
from chain_signer import preflight

spender = "0x" + "22" * 20 tx = {"to": "0x" + "33" * 20, "data": "0x095ea7b3" + spender[2:].rjust(64, "0") + "f" * 64, "value": 0} print(preflight(tx)) # ok=False — flags unlimited_approval before you'd ever sign

That's the wedge: the drain gets flagged before you'd ever sign it — no key, no funds, no network.
Bundled wallet (optional — the guards pair with any wallet)
from chain_signer import burner, send_ether

from chain_signer.balance import get_balance

w = burner() # fresh throwaway wallet; the agent owns w.private_key print(w.address, get_balance(w)) # live on-chain balance send_ether(w, "0x...recipient", 0.001) # auto nonce+gas, signed locally, broadcast

Full runnable demos are in the repo: `examples/agent_safety_demo.py` (all three guards stop three

real attacks) and examples/quickstart.py (wallet) — clone to run them, or just import as above.

Safety preflight (the wedge)

Before an agent signs, hand the unsigned tx to preflight() — it decodes the calldata and returns the risks, or use assert_safe() to hard-stop on a HIGH flag. Offline, no network, never raises.

from chain_signer import preflight, assert_safe

an unlimited-allowance approve() to a spender — the classic drain setup

tx = {"to": token, "data": "0x095ea7b3" + spender_padded + "f"*64, "value": 0}

report = preflight(tx)

{'decoded': {...}, 'ok': False,

'risk_flags': [{'code': 'unlimited_approval', 'severity': 'HIGH',

'detail': 'approve() grants an effectively-unlimited allowance ...'}]}

assert_safe(tx) # raises ValueError on a HIGH flag; pass force=True to override assert_safe(tx, sim=my_simulator) # optional: also flag will-revert via your simulation hook

What it flags today: unlimited/large approval, `increaseAllowance`, `setApprovalForAll`,

ERC-20 transferFrom + ERC-721/1155 safeTransferFrom (token & NFT drains), ERC-777 authorizeOperator/operatorSend (operator-grant + operator-pull drains), on-chain ERC-2612 and DAI-style permit, on-chain Permit2 approve/permit/transferFrom (single and batch — the dominant approval router: unlimited uint160 allowance + drain pull) plus Permit2 SignatureTransfer permit(Witness)TransferFrom (the one-shot signed-permit pull intent/filler protocols use), proxy upgradeTo/upgradeToAndCall, approvals hidden inside multicall (all router variants, nested) and Multicall3 `aggregate`/`aggregate3`/`aggregate3Value` (the canonical batch helper deployed at one address on every EVM chain), approvals wrapped in ERC-4337/smart-account execute/executeBatch, Gnosis Safe multiSend/execTransaction, or DSProxy execute(target,data)/execute(code,data) (decoded and recursed), drains routed through the Uniswap Universal Router (execute(commands,inputs) — Permit2 permit/transferFrom commands, batch and EXECUTE_SUB_PLAN), EIP-7702 account delegation (the "wallet upgrade" drainer), large native value, opaque calldata, malformed calls, and will-revert (with a sim hook). Honest limits (read these): this is STATIC analysis — it decodes calldata and matches known drain patterns. It is NOT a transaction simulator: it won't catch a novel/obfuscated drain it can't decode (those get a low-severity "unknown" flag, not a block), and simulation-based scanners go deeper there. Safety coverage is EVM-only today (no Solana/Bitcoin tx analysis). And it is not yet field-proven at scale. A first-line guard for known patterns — not a guarantee. Pair it with simulation + human review for high-value actions.

Signed-message inspector (the off-chain half)

A drain doesn't need a transaction. A dApp can ask the agent to sign an EIP-712 message — most dangerously a permit granting an unlimited token allowance, which preflight (a tx check) can't see. inspect_typed_data() catches it before the agent signs:

from chain_signer import inspect_typed_data

report = inspect_typed_data(typed_data) # the EIP-712 object you're about to sign

ok=False, risk_flags=[{'code': 'unlimited_permit_signature', 'severity': 'HIGH', ...}]

Covers all three major permit shapes: **ERC-2612**, **Uniswap Permit2** (PermitSingle/PermitBatch, plus

SignatureTransfer and the witness variants intent protocols use), and DAI-style (allowed: true), plus Seaport marketplace orders that hand assets over for nothing — zero consideration, proceeds routed to a third party while your asset leaves, or the same giveaway buried in a BulkOrder merkle tree. Offline, never raises.

Guarded signer (screen + sign in one call)

inspect_typed_data only protects when the agent remembers to call it first — sign_typed_data alone will happily sign a permit-phishing message. guarded_sign_typed_data() composes the two so signing is screened by default: it inspects, then refuses to sign a HIGH-risk drain.

from chain_signer import guarded_sign_typed_data, SignatureBlocked

sig = guarded_sign_typed_data(wallet, domain, types, message, "Permit") # raises SignatureBlocked on a drain

On a clean message the signature is byte-identical to `sign_typed_data`; pass `force=True` to override.

Action-policy gate (inspect what the agent DOES)

Identity tells you *who* the agent is; it doesn't stop a bad *action*. check_action() enforces a policy on a proposed tool call before it runs — fail-safe (denies on unreadable input):

from chain_signer import check_action

policy = {"forbid_tools": ["bridge"], "max_value_wei": 10**18, "allow_recipients": [trusted_addr]} r = check_action({"tool": "send", "args": {"to": addr, "value_wei": 5*10**18}}, policy)

{'allowed': False, 'violations': [{'code': 'value_over_limit', ...}]}

All three guards are exposed as MCP tools (preflight, inspect_signature, check_action) — any agent runtime (Claude, Cursor, …) can call them directly, read-only, no key.

What's caught and what isn't — the honest threat-coverage map: docs/THREAT-COVERAGE.md.

What you get

  • preflight(tx) / assert_safe(tx) — decode an unsigned tx and flag drain patterns before signing.
  • inspect_typed_data(td) — flag permit-phishing in an EIP-712 message before the agent signs it.
  • guarded_sign_typed_data(w, domain, types, message, primary_type) — screen then sign; refuses a drain.
  • check_action(action, policy) — enforce allow/forbid + value/recipient limits before the agent acts.
  • burner() — a fresh wallet for a one-off task; discard it when done.
  • restore(key) — reload a wallet later from its exported private key (same key → same address).
  • send_ether(w, to, amount) — send in ETH (not wei); nonce, gas, and broadcast handled for you.
  • get_balance(w) — live balance from the chain (Etherscan v2 indexer, not a flaky public RPC).
  • swap(...) — token swaps via 0x/Paraswap.
  • Optional Solana + Bitcoin wallets via the [all] extra.

Non-custodial guarantee

The private key is generated/loaded locally, used only to sign, and never logged, returned, or stored by this library. You hold the key; we never touch your funds. That is the whole design.

Handling the key (read this)

w.private_key is the keys to the wallet. Treat it like a password:

  • NEVER log it, print it in production, or write it into notes/memory/chat. Anyone who has it controls the funds.
  • For a burner holding a few dollars this is low-stakes by design — but the rule still holds.
  • To reuse a wallet later, store the key in a secret manager / env var, then restore(key).
  • Better: export_encrypted(w, password) gives a password-protected keystore dict to store at rest; load_encrypted(keystore, password) brings the wallet back. Never store the raw key if you can store the keystore.

Signing idiom (note for web3.py users)

The wallet does not expose sign_transaction / sign_message methods. Signing is done by function helpers you pass the wallet to — e.g. send_ether(w, to, amount) signs and broadcasts, and sign_message(w, "text") returns an EIP-191 signature for auth / sign-in flows (recoverable via eth_account Account.recover_message).

CLI on PATH

pip install may warn that the chain-signer script dir isn't on your PATH. The library works regardless; to use the CLI directly, add that dir to PATH or run python -m chain_signer ....

Tool surface (for any AI / MCP / CLI)

chain_signer.mcp_server exposes list_tools() and call_tool(name, arguments). CLI:

python -m chain_signer list

python -m chain_signer call create_wallet '{"chain":"evm"}'

Responsible use

General-purpose, non-custodial tooling. You are responsible for using it within the laws and terms of service that apply to you. Not intended or marketed for any restricted or prohibited trading in your jurisdiction.

Notes

  • Balances/broadcast use the Etherscan v2 indexer (authoritative), never a free public RPC.
  • Low-level building blocks (tx.send, call_contract, explicit nonce/gas) remain available for advanced use.

Pay an x402 API in one call

from chain_signer import burner, sign_x402_payment

w = burner() payload = sign_x402_payment(w, token=USDC, to=PAY_TO, value=1000, valid_before=EXPIRES, chain_id=8453)

-> {"signature", "authorization"} ready for the x402 payment header. Signed locally, no prompt.

Builds + signs the EIP-3009 authorization x402 expects (the "exact" scheme). Your agent pays a

paid API by itself — no password prompt, no signup, no custody.

Sig

Nur der Anfang wird gezeigt; den Rest findest du im Repo

PopNx fragen