How do I use StealthPay MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@StealthPay MCP send 10 USDC to vitalik.eth privately" 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.

StealthPay MCP

by mandalito

Overview Schema Related Servers Score Discussions

TypeScript

StealthPay MCP

StealthPay MCP is a hackathon project built for:

It is an MCP server that gives AI agents the ability to make contextual, private crypto payments using ENS identity and stealth addresses.

Problem

Agentic crypto payments are still not contextual enough:

An agent may know the recipient identity, but not their payment preferences (chain, token, UX constraints).
ENS identity is human-readable, but often not structured as machine-usable payment instructions.
Reusing one public address for many receipts creates onchain correlation and harms privacy.

StealthPay targets this double problem: smarter machine-readable payment routing, plus private receiving with one-time stealth addresses.

Related MCP server: remit.md MCP Server

Solution

StealthPay MCP turns an ENS name into a machine-usable payment endpoint:

reads recipient payment preferences from CAIP-normalized ENS profile data (stealthpay.v1.* namespace)
builds the payment path for the right chain/token context with stealth/note policy enforcement
uses stealth-address flow (ERC-5564-style announcements) for private receipt discovery
encrypts payment notes using recipient viewing keys (ChaCha20-Poly1305)
enforces agent spend policy controls (per-tx caps, daily limits, chain/token/destination allowlists)

What is MCP?

MCP (Model Context Protocol) is a standard way for AI clients/agents to call external tools.
In this project, MCP tools expose payment capabilities (get-payment-profile, send-stealth-payment, scan-announcements, claim-stealth-payment) in a structured, automatable interface.

What is a stealth address?

A stealth address is a one-time recipient address derived from a published stealth meta-address.
Each payment can use a fresh address, so receipts are harder to correlate publicly while still being recoverable by the intended recipient.

How StealthPay differs from Umbra / Fluidkey

StealthPay is not trying to replace those products. It focuses on a different layer:

MCP-native (agentic) interface: StealthPay exposes tools through MCP for AI/agent orchestration; Umbra and Fluidkey are not MCP tool surfaces.
Programmable payment profiles: StealthPay routes payments from ENS-stored machine-readable preferences (chain/token/UX policy), not only identity lookup.
Centralization model: StealthPay is an open, self-hostable MCP server; Fluidkey is a managed product with centralized service components.
Stealth standard positioning: Umbra pioneered stealth payments, but its original architecture predates the latest stealth-address standardization work; StealthPay targets ERC-5564-style announcement/scan flows in an agent-friendly pipeline.
End-to-end machine flow: resolve identity -> generate stealth destination -> pay -> scan -> claim, from one MCP surface.

Example use cases

AI assistant pays a freelancer from a plain request: "Send 50 USDC to alice.eth privately."
Operations bot executes recurring payouts to contributors while preserving recipient privacy.
Checkout/commerce assistant generates ENS-based private payment links for one-off customer settlements.
DAO/grant tooling sends disbursements with identity-level routing and reduced receipt linkage.

Send crypto to anyone with an ENS name — privately. The recipient's address is never reused or publicly linked to their identity.

How it works

Sender (AI agent)                         Recipient
────────────────                          ─────────
1. Look up bob.eth                        (published stealth meta-address)
2. Generate one-time stealth address      ← fresh address, unlinkable to bob.eth
3. Send tokens to stealth address         ← on-chain transfer
4. Announce via ERC-5564                  ← so recipient can discover it
                                          5. Scan announcements → find payment
                                          6. Claim via `claim-stealth-payment`
                                             (derive + withdraw server-side)

Nobody except the recipient can tell they received the payment. The stealth address has never appeared on-chain before and cannot be linked to their public ENS name.

Quick start

Install

git clone https://github.com/mandalito/StealthPay-MCP.git
cd StealthPay-MCP
npm install
npm run build

Configure environment

cp .env.example .env

Edit .env:

# Required: wallet private key for sending payments / registering ENS names
SENDER_PRIVATE_KEY=0x<your-private-key>

# For testnet: set ENS resolution to Sepolia
ENS_CHAIN=sepolia

# Optional: custom RPC endpoints (defaults to public RPCs)
# RPC_URL=https://eth-sepolia.g.alchemy.com/v2/<key>
# ENS_RPC_URL=https://...

# Optional: recipient keys (for scan/claim flows)
# Fill these from `register-stealth-keys` output
# RECIPIENT_SPENDING_PRIVATE_KEY=0x...
# RECIPIENT_SPENDING_PUBLIC_KEY=0x...
# RECIPIENT_VIEWING_PRIVATE_KEY=0x...
# RECIPIENT_VIEWING_PUBLIC_KEY=0x...

# Optional: agent spend policy controls
# POLICY_MAX_PER_TX=0.1                    # Per-transaction cap in ETH (default: 0.1)
# POLICY_MAX_DAILY_SPEND=1.0               # Rolling 24h limit in ETH (default: 1.0)
# POLICY_CHAIN_ALLOWLIST=sepolia,base       # Comma-separated; empty = all allowed
# POLICY_TOKEN_ALLOWLIST=ETH,USDC           # Comma-separated; empty = all allowed
# POLICY_DESTINATION_ALLOWLIST=alice.eth     # Comma-separated; empty = all allowed
# POLICY_ADMIN_ADDRESS=0x...                # Admin key for signed policy updates
# POLICY_IMMUTABLE=false                    # If true, blocks agent policy field changes via set-profile
# POLICY_VERSION=0                          # Policy schema version (for rollback protection)
# POLICY_EFFECTIVE_AT=2026-01-01T00:00:00Z  # ISO 8601 policy effective timestamp

Recipient key handling:

register-stealth-keys generates recipient keys and saves them directly to local .env.
Private keys are not returned through MCP output to the AI/client surface.
Only the stealth meta-address is written on-chain; private keys are never stored on-chain.
.env is gitignored, so these secrets stay local unless you export them elsewhere.

Security Model

StealthPay MCP follows one non-negotiable rule: private keys must never be exposed to the agent model under any circumstances.

Key philosophy

Agents can trigger MCP tools, but they must not receive private key material in tool inputs or outputs.
This includes sender account keys, recipient spending/viewing keys, and derived stealth private keys.
Secret material should remain inside the MCP runtime boundary only.

Operator responsibilities (install/deploy)

Store keys in a secure local haven on your device (OS keychain, encrypted secret store, or equivalent).
Ensure the secret store is reachable by MCP runtime but not directly reachable by the agent process.
Never paste keys into chat, prompts, or tool arguments.
Prefer runtime secret injection over plaintext files when possible.
If you use .env for local development, keep it local, gitignored, permission-restricted, and outside shared/synced folders.
Rotate any key immediately if exposure is suspected.

Current security controls in this repo

register-stealth-keys writes generated keys locally and does not return private keys in MCP output.
scan-announcements and claim-stealth-payment use env-only recipient key paths; key-bearing inputs are not part of tool schemas.
Derived stealth private keys are used server-side for claim execution and are never returned to agent/client output.
derive-stealth-key and withdraw-from-stealth are not registered MCP tools.
Agent spend policy engine (src/lib/policy.ts) enforces per-tx caps, daily limits, and allowlists on every transaction path.
POLICY_IMMUTABLE=true prevents agents from modifying policy fields via set-profile.
Signed policy updates require a pinned POLICY_ADMIN_ADDRESS with version monotonicity (rollback protection).
All policy events (load, check pass/fail, update accept/reject) are audit-logged to stderr.
A test (test/tools/no-secrets-in-docs.test.ts) scans docs/examples for private-key-like hex strings.

Operational recommendations

Use dedicated low-fund operational wallets, not personal main wallets.
Do not run DEBUG=true test flows with real funds/keys.
Treat logs, chat history, shell history, and screenshots as sensitive channels.
Set POLICY_MAX_PER_TX and POLICY_MAX_DAILY_SPEND to appropriate limits for your use case.
Set POLICY_IMMUTABLE=true in production to prevent agents from modifying payment policies.

Add to Claude Code

Global (available in all projects) — add to ~/.claude/.mcp.json:

{
  "mcpServers": {
    "stealthpay": {
      "command": "node",
      "args": ["/absolute/path/to/StealthPay-MCP/dist/index.js"],
      "cwd": "/absolute/path/to/StealthPay-MCP"
    }
  }
}

Project-only — add a .mcp.json in your project root with the same content.

Then restart Claude Code. The 13 registered tools will be available immediately.

Tools

Identity

Tool	Description
`get-my-profile`	Show current wallet, reverse ENS name, payment profile, and recipient-key status
`generate-wallet`	Generate and persist a local sender wallet in `.env`
`get-balances`	Check native/token balances of your sender wallet on a selected chain

Onboarding & Profile

Tool	Description
`register-ens-name`	Register a .eth name (commit → wait → register flow, ~65s)
`register-stealth-keys`	Generate spending/viewing keypairs and set the stealth-meta-address text record on your ENS name
`set-profile`	Set payment preferences on your ENS name: preferred chain, token, stealth policy, and note preferences. Writes to both `stealthpay.v1.*` and legacy ENS text records.
`set-primary-name`	Set the ENS reverse record so your wallet address resolves back to your ENS name.

Sending payments

Tool	Description
`get-payment-profile`	Resolve ENS name → address, avatar, CAIP-normalized chain/token preferences, stealth meta-address, stealth/note policies
`generate-stealth-address`	Generate a one-time stealth address from an ENS name
`send-stealth-payment`	Send ETH / stablecoins / ERC-20 to a stealth address + announce via ERC-5564. Enforces recipient stealth/note policies and agent spend limits. Supports encrypted memos.
`create-payment-link`	Generate a shareable payment link (web URL + ERC-681 URI)

Receiving payments

Tool	Description
`scan-announcements`	Scan ERC-5564 events to discover payments addressed to you
`claim-stealth-payment`	Derive + withdraw in one step using locally stored recipient keys (keys never pass through AI)

Chain support and requirements

StealthPay flows depend on different on-chain requirements depending on the feature:

ENS onboarding/resolution (register-ens-name, register-stealth-keys, get-payment-profile, generate-stealth-address) requires ENS contracts and an ENS-capable RPC on the selected ENS_CHAIN.
Stealth payment flows (send-stealth-payment, scan-announcements, claim-stealth-payment) require:
- ERC-5564 announcer deployment
- ERC-6538 registry deployment
- reachable RPC on the payment chain

Live deployment check (via eth_getCode) on 2026-03-21 for configured singleton addresses:

Chain	ERC-5564 announcer (`0x5564...5564`)	ERC-6538 registry (`0x6538...6538`)
ethereum	deployed	deployed
base	deployed	deployed
optimism	deployed	deployed
arbitrum	deployed	deployed
polygon	deployed	deployed
gnosis	deployed	deployed
sepolia	deployed	deployed
hoodi	not deployed	not deployed

ENS requirements

ENS registration and resolver write operations are currently implemented for sepolia and ethereum only (see ENS_CONTRACTS).
ENS resolution defaults to ethereum unless ENS_CHAIN=sepolia is set.
Hackathon baseline uses Sepolia for both ENS and payment execution.

Practical support summary

Operational now: ethereum, base, optimism, arbitrum, polygon, gnosis, sepolia (for stealth announcement/scan primitives).
Not operational yet: hoodi (contracts missing at configured singleton addresses).

Programmable payment profile

StealthPay implements CAIP-normalized payment profiles using the stealthpay.v1.* ENS text record namespace. The set-profile tool writes both namespaced v1 keys and legacy keys for backwards compatibility. The get-payment-profile tool reads v1 keys first, with legacy fallback.

Canonical keys (stealthpay.v1.*):

Key	Type	Example
`stealthpay.v1.profile_version`	string	`"1"`
`stealthpay.v1.preferred_chains`	CSV	`"eip155:8453,eip155:10"` (CAIP-2)
`stealthpay.v1.preferred_assets`	CSV	`"eip155:8453/erc20:0x833..."` (CAIP-19)
`stealthpay.v1.stealth_policy`	enum	`required \| preferred \| optional \| disabled`
`stealthpay.v1.stealth_scheme_ids`	CSV	`"1"`
`stealthpay.v1.note_policy`	enum	`required \| optional \| none`
`stealthpay.v1.note_max_bytes`	number	`"140"`
`stealthpay.v1.note_privacy`	enum	`plaintext \| encrypted \| hash_only`

Legacy keys (avatar, chain, token, stealth-meta-address, description) are still read as fallbacks and written alongside v1 keys during the migration window.

A machine-readable JSON Schema is published at schemas/payment-profile.schema.json.

Announcement metadata format

Stealth transfer announcement metadata (ERC-5564 event payload) is encoded as:

viewTag (1 byte)
selector (4 bytes, ERC-20 transfer selector or 0x00000000 for native)
tokenAddress (20 bytes, 0x00...00 for native ETH)
amount (32 bytes, uint256)
memo (variable bytes, UTF-8 plaintext, encrypted envelope, or keccak256 hash — per recipient notePrivacy preference)

Testing

# Endpoint contract tests (all MCP tools, mocked deps)
npm run test:tools

# Unit tests (stealth math, payment links — no network)
npm run test:unit

# Default deterministic suite (unit + tool tests)
npm test

# ENS integration test (reads mainnet ENS; set ENS_RPC_URL for a reliable run)
npm run test:ens

# Re-check onchain singleton deployments across configured chains
npm run check:deployments

# Sepolia fork integration (on-demand)
# Uses SEPOLIA_FORK_URL (or RPC_URL fallback) as fork upstream.
# Set FORK_REQUIRED=true to fail hard if fork node cannot start.
npm run test:fork

# Full Sepolia E2E (send → announce → scan → claim)
# Requires SENDER_PRIVATE_KEY with Sepolia ETH
npm run test:e2e

# ENS flow E2E (resolve ENS → stealth address → send → scan)
npx tsx test/ens-e2e.ts

# Register ENS name + set stealth keys E2E
npx tsx test/register-e2e.ts <label>

Notes:

*.test.ts files are deterministic Vitest suites.
*-e2e.ts files are executable integration runners (live-network utilities), not part of default npm test.

Get Sepolia testnet ETH

Go to https://sepoliafaucet.com
Paste your wallet address
Run npm run test:e2e

Architecture

src/
├── index.ts                 # MCP server entry point (12 registered tools)
├── config.ts                # Chain configs, contract addresses, ABIs, CAIP helpers
├── lib/
│   ├── stealth.ts           # ERC-5564 stealth address math (secp256k1)
│   ├── ens.ts               # ENS resolution + payment profile (dual-read v1/legacy)
│   ├── ens-register.ts      # ENS name registration + text record setting
│   ├── profile.ts           # Payment profile types, ENS key mappings, validation
│   ├── payments.ts          # Token transfer + ERC-5564 announcement + note encryption
│   ├── scanner.ts           # Scan Announcement events, discover payments
│   ├── withdraw.ts          # Withdraw funds from stealth addresses
│   ├── policy.ts            # Agent spend policy engine (caps, limits, allowlists, audit)
│   └── note-encryption.ts   # Encrypted notes (ChaCha20-Poly1305, baseline + dual-envelope)
└── tools/                   # MCP tool wrappers (thin layer over lib/)
    ├── register-ens-name.ts
    ├── register-stealth-keys.ts
    ├── set-profile.ts
    ├── get-payment-profile.ts
    ├── generate-stealth-address.ts
    ├── send-stealth-payment.ts
    ├── create-payment-link.ts
    ├── get-my-profile.ts
    ├── generate-wallet.ts
    ├── get-balances.ts
    ├── scan-announcements.ts
    └── claim-stealth-payment.ts
schemas/
└── payment-profile.schema.json  # Machine-readable JSON Schema for payment profiles

Local Helpers (`.local/`)

.local/ is a gitignored workspace for local-only artifacts:

cloned external repos used for reference (for example Umbra SDK source)
temporary MCP probe scripts (.mjs) used to exercise tools over stdio during debugging

These scripts are not part of the production server and are not committed.

Standards

ERC-5564 — Stealth Addresses (announcement)
ERC-6538 — Stealth Meta-Address Registry
MCP — Model Context Protocol

Dependencies

Package	Purpose
`@modelcontextprotocol/sdk`	MCP server
`@noble/secp256k1`	Elliptic curve math (stealth addresses, ECDH)
`@noble/hashes`	Hashing (HKDF-SHA256, keccak256 peer dep)
`@noble/ciphers`	Symmetric encryption (ChaCha20-Poly1305 for encrypted notes)
`viem`	ENS + transactions + keccak256
`zod`	Input validation
`dotenv`	Environment variable loading

Known limitations

Token-only stealth account cannot withdraw without native gas: If a stealth account receives non-native tokens but has 0 native ETH, withdrawal fails until gas is funded. Gasless/paymaster is not in hackathon MVP scope.
Hoodi testnet status: Chain config exists, but production-grade ERC-5564/6538 readiness remains unvalidated for this repo.
Metadata format compatibility: Scanner parsing assumes this project's metadata conventions; other ERC-5564 senders may encode differently.
In-memory spend ledger: Daily spend tracking is in-process only and resets on server restart. Persistent storage is a future enhancement.

Future improvements

Add ERC-4337/paymaster withdrawal flow so stealth accounts can move token-only balances without pre-funding native gas.
Add send-stealth-payment mode for unsigned payload generation (build_unsigned_tx) in addition to direct execution.
Improve scan performance/reliability with indexed backends (subgraph/indexer) and rate-limit-aware pagination.
Persist spend ledger to disk or external store for daily limit continuity across restarts.
Complete Umbra SDK integration path where it improves maintainability without breaking current ERC-5564/6538 behavior.

License

MIT

Available Tools

7 tools

claim-stealth-paymentClaim Stealth PaymentA

Destructive

Derive the stealth private key and withdraw funds in one step. Uses RECIPIENT_SPENDING_PRIVATE_KEY and RECIPIENT_VIEWING_PRIVATE_KEY from environment — private keys never pass through AI. Only the ephemeral public key (from scan-announcements) and destination address are needed.

ParametersJSON Schema

Name	Required	Description	Default
`to`	Yes	Destination address to receive funds (0x-prefixed)
`chain`	No	Chain (default: sepolia). Supported: ethereum, base, optimism, arbitrum, polygon, gnosis, sepolia, hoodi	sepolia
`token`	Yes	Token to withdraw: "ETH" for native, or ERC-20 contract address
`amount`	No	Amount to withdraw (human-readable). Omit to withdraw full balance.
`ephemeralPublicKey`	Yes	Ephemeral public key from the ERC-5564 announcement (from scan-announcements output)

Output Schema

ParametersJSON Schema

Name	Required	Description
`to`	Yes
`from`	Yes
`chain`	Yes
`token`	Yes
`amount`	Yes
`txHash`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

The description discloses key derivation, environment key usage, and that private keys never pass through AI. This adds value beyond the destructiveHint annotation. No contradiction with annotations.

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

Conciseness5/5

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

Two sentences: first states action, second explains security and key inputs. No redundancy; all information is essential and well-structured.

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

Completeness4/5

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

The description covers the core action and security but does not mention prerequisites (e.g., prior scan-announcements) or output details. Output schema exists, so return values are likely documented elsewhere.

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%, but the description adds context that only ephemeralPublicKey and to are needed (others optional/default). This helps the agent prioritize inputs beyond schema descriptions.

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 clearly states the tool derives the stealth private key and withdraws funds in one step, specifying required inputs (ephemeral public key from scan-announcements, destination address). It distinguishes from siblings like generate-stealth-address and send-stealth-payment by focusing on claiming.

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

Usage Guidelines3/5

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

The description implies usage after scanning announcements but lacks explicit when/why advice or exclusion criteria. It does not compare to sibling tools or state prerequisites clearly.

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

create-payment-linkCreate Payment LinkA

Read-onlyIdempotent

Generate a shareable payment link for an ENS name. The link resolves to a stealth address at payment time, ensuring privacy.

ParametersJSON Schema

Name	Required	Description
`to`	Yes	Recipient ENS name (e.g. "vitalik.eth")
`memo`	No	Optional memo for the payment
`chain`	No	Preferred chain (e.g. "base")
`token`	No	Token symbol (e.g. "USDC")
`amount`	No	Suggested amount (e.g. "50.00")

Output Schema

ParametersJSON Schema

Name	Required	Description
`webUrl`	Yes
`erc681Uri`	Yes
`recipient`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context about the link resolving to a stealth address at payment time, explaining the privacy mechanism. No contradictions with annotations.

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

Conciseness5/5

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

The description is two sentences, directly stating the purpose and key feature. No wasted words, and the key action is front-loaded.

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

Completeness4/5

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

Given annotations and full schema coverage, the description is mostly complete. It explains the output's privacy characteristic. The output schema (not shown) likely covers return format, so no missing context.

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

Parameters3/5

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

Schema coverage is 100% with clear descriptions for all 5 parameters. The tool description adds no additional parameter-level meaning beyond the schema, so baseline 3 is appropriate.

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 clearly states the verb ('Generate a shareable payment link') and resource ('ENS name'), and distinguishes it from siblings like 'generate-stealth-address' and 'send-stealth-payment' by specifying the output is a shareable link with privacy features.

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 description implies usage for creating a privacy-preserving payment link, but does not explicitly state when to use this tool over siblings like 'generate-stealth-address' or 'send-stealth-payment'. No when-not-to-use guidance is provided.

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

generate-stealth-addressGenerate Stealth AddressB

Read-only

Generate a one-time stealth address for a recipient using their ENS name. The resulting address can only be controlled by the recipient, but cannot be linked to their public identity.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	ENS name of the recipient (e.g. "vitalik.eth")

Output Schema

ParametersJSON Schema

Name	Required	Description
`viewTag`	Yes
`recipient`	Yes
`stealthAddress`	Yes
`ephemeralPublicKey`	Yes

TDQS

B3.4/5.0

Behavior1/5

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

The description uses 'generate' which implies a write/mutation, but annotations have readOnlyHint=true, creating a direct contradiction. No additional behavioral traits beyond the annotations are disclosed, and the contradiction undermines trust.

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

Conciseness5/5

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

The description is two sentences, front-loaded with the action and resource, and the second sentence adds value about privacy and control. No wasted words.

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

Completeness4/5

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

Given the simple input and existence of an output schema (not shown), the description covers the core functionality and privacy aspect. It could mention prerequisites like ENS resolution, but it's largely complete for a straightforward tool.

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

Parameters3/5

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

Schema coverage is 100% with a clear description for the 'name' parameter. The description merely restates 'using their ENS name', adding no extra semantics beyond the schema. Baseline of 3 is appropriate.

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 clearly states the verb 'generate' and the resource 'stealth address' for a recipient via ENS name. It distinguishes from sibling tools like 'claim-stealth-payment' and 'send-stealth-payment' by focusing on generation.

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

Usage Guidelines3/5

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

The description explains the privacy benefit (unlinkable) but does not explicitly guide when to use this tool versus alternatives like 'send-stealth-payment' or 'claim-stealth-payment'. Usage context is implied but lacks when-not-to-use guidance.

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

get-payment-profileGet Payment ProfileA

Read-onlyIdempotent

Resolve an ENS name and fetch the recipient's payment profile: address, avatar, preferred chain/token, and stealth meta-address.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	ENS name (e.g. "vitalik.eth")

Output Schema

ParametersJSON Schema

Name	Required	Description
`avatar`	Yes
`address`	Yes
`ensName`	Yes
`notePolicy`	Yes
`description`	Yes
`notePrivacy`	Yes
`noteMaxBytes`	Yes
`stealthPolicy`	Yes
`preferredChain`	Yes
`preferredToken`	Yes
`preferredAssets`	Yes
`preferredChains`	Yes
`stealthSupported`	Yes
`stealthMetaAddress`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds value by listing the specific fields returned, which goes beyond annotations. No contradictions. A score of 4 is appropriate as the description contributes useful behavioral context.

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

Conciseness5/5

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

Single sentence, no unnecessary words, front-loaded with the action (resolve and fetch). Perfectly concise for the information density.

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

Completeness4/5

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

The tool has an output schema, so return values are covered. The description explains the input and what the tool does. Minor omission: no mention of error behavior if ENS name does not exist. But overall complete for a simple read operation with good annotations.

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% and parameter description already provides 'ENS name (e.g. vitalik.eth)'. The tool description adds context about resolving the name and fetching a payment profile, giving operational meaning. This elevates the baseline from 3 to 4.

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?

Description clearly states the verb 'resolve' and resource 'ENS name' and specifies the output fields: address, avatar, preferred chain/token, stealth meta-address. This distinguishes it from siblings like generate-stealth-address or register-ens-name.

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 description implies usage: when you have an ENS name and need payment profile details. It doesn't explicitly state when to avoid it or name alternatives, but the context of siblings makes it clear. A score of 4 reflects clear context without exclusions.

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

Register a new .eth ENS name. Checks availability, computes cost, and completes the commit-wait-register flow. Takes ~65 seconds due to the commitment waiting period. Uses SENDER_PRIVATE_KEY from environment.

ParametersJSON Schema

Name	Required	Description	Default
`chain`	No	Chain for ENS registration. Supported: sepolia, ethereum	sepolia
`label`	Yes	Name to register (without .eth suffix, e.g. "myname")
`years`	No	Registration duration in years (default: 1)

Output Schema

ParametersJSON Schema

Name	Required	Description
`cost`	Yes
`name`	Yes
`chain`	Yes
`owner`	Yes
`expiresIn`	Yes
`commitTxHash`	Yes
`registerTxHash`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Adds behavioral context beyond annotations: checks availability, computes cost, describes the three-step flow, and notes the 65-second delay. No contradiction with annotations (readOnlyHint=false, not idempotent, not destructive).

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

Conciseness5/5

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

Three concise sentences, front-loaded with purpose, no filler. Every sentence contributes meaningful information.

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 output schema exists, description adequately covers flow, timing, environment variable, and parameter hints. No gaps for a registration tool.

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

Parameters3/5

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

Schema coverage is 100% with clear descriptions. Description adds minor clarification (e.g., 'without .eth suffix') but doesn't add significant meaning beyond what schema already provides.

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?

Description clearly states 'Register a new .eth ENS name' with specific verb and resource. It distinguishes from siblings like 'set-primary-name' by describing the full commit-wait-register flow for initial registration.

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?

Description provides timing guidance (~65 seconds waiting period) and mentions environment variable for private key. Lacks explicit when-to-use vs alternatives but gives sufficient context for agent to decide.

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

send-stealth-paymentSend Stealth PaymentA

Destructive

Send a private payment to an ENS name using a stealth address. Supports native ETH, known stablecoins (USDC, USDT, DAI), or any ERC-20 by contract address. Generates a one-time address, sends the funds, and announces via ERC-5564.

ParametersJSON Schema

Name	Required	Description
`to`	Yes	Recipient ENS name (e.g. "vitalik.eth")
`memo`	No	Optional payment note/memo. Encoded in the ERC-5564 announcement metadata so the recipient can read it when scanning.
`chain`	No	Chain to send on. If omitted, uses the recipient's preferred chain or defaults to sepolia. Supported: ethereum, base, optimism, arbitrum, polygon, gnosis, sepolia, hoodi
`token`	No	Token: "ETH" for native, a symbol like "USDC", or a 0x ERC-20 contract address. If omitted, uses the recipient's preferred token or defaults to ETH.
`amount`	Yes	Amount to send (e.g. "0.01" or "100.00")

Output Schema

ParametersJSON Schema

Name	Required	Description
`chain`	Yes
`token`	Yes
`amount`	Yes
`recipient`	Yes
`announceFailed`	Yes
`announceTxHash`	Yes
`stealthAddress`	Yes
`transferTxHash`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Annotations declare destructiveHint=true. Description adds that it generates a one-time address, sends funds, and announces via ERC-5564, providing useful behavioral context beyond annotations.

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?

Three sentences, front-loaded with key action. Slightly verbose with 'Supports...' phrase but overall efficient and focused.

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

Completeness4/5

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

Given output schema presence, description covers sending flow. Lacks mention of prerequisites (e.g., recipient must have payment profile) but adequate for typical use.

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

Parameters5/5

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

All 5 parameters are described in schema (100% coverage). Description enhances memo, chain, and token with additional detail (e.g., encoding, supported chains, token resolution).

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?

Clearly states sending a private payment to an ENS name via stealth address, lists supported tokens and ERC-5564. Distinguishes from siblings like generate-stealth-address and claim-stealth-payment.

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?

Implies use for sending private payments, but does not explicitly differentiate from alternatives like generate-stealth-address or claim-stealth-payment. No exclusions or prerequisites mentioned.

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

set-primary-nameA

Set the primary ENS name (reverse record) for your wallet. After this, your address resolves to the given ENS name.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	ENS name to set as primary (e.g. "myname.eth")
`chain`	No	Chain (default: sepolia)

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, description carries full burden. It discloses the core behavior (sets reverse record) and outcome (address resolves to name). However, lacks details on mutation, permissions, reversibility, or costs.

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

Conciseness5/5

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

Two sentences, front-loaded with key verb and resource, no wasted words. Highly concise and structured.

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

Completeness4/5

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

Given no output schema, the description covers purpose and outcome adequately. Missing prerequisites (must own the ENS name) and error conditions, but for a simple setter it is fairly complete.

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

Parameters3/5

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

Schema coverage is 100% with descriptions for both parameters. The description adds context ('reverse record') but does not significantly enhance beyond schema. Baseline 3 is appropriate.

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

Purpose4/5

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

The description clearly states the action: setting primary ENS name for wallet, with the effect of address resolution. It distinguishes from sibling tools like 'register-ens-name' by focusing on reverse record, but does not explicitly differentiate.

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

Usage Guidelines3/5

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

Implied usage when you want your address to resolve to a given ENS name, but no explicit when-to-use, when-not-to-use, or alternatives. No mention of prerequisites like owning the name.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Disambiguation5/5

Each tool has a distinct and clear purpose, covering separate actions like generating addresses, sending payments, managing ENS names, resolving profiles, creating payment links, and claiming funds. There is no overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb-noun pattern with hyphens (e.g., generate-stealth-address, send-stealth-payment). The naming is predictable and uniform throughout the set.

Tool Count5/5

With 7 tools, the server is well-scoped for its privacy-focused payment domain. Each tool is essential and covers key operations without unnecessary bloat or missing core functionality.

Completeness3/5

The tool surface covers most of the stealth payment workflow, but a critical tool for scanning announcements (as referenced in claim-stealth-payment) is missing, creating a dependency on external inputs. Additionally, no tools for balance checks or transaction history are provided.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

AgentPays
dev.agentpays
Payment infrastructure for AI agents: spending rules, approval flows, single-use virtual cards.
Payments & Billing Autonomous Agents
2
MIDAS Protocol C
io.github.BbrainFrance
Complete financial infrastructure for AI agents — payments, lending, escrow & more.
Finance Payments & Billing
2
mcp A
io.github.ShieldZCash
Keyless non-custodial crypto payments for AI agents: payment links and tip jars, no API key.
Cryptocurrency Payments & Billing
42
cred
fyi.cred
Agentic payments.
Payments & Billing Finance
2

Related MCP Servers

Armor Crypto MCP
Cryptocurrency Blockchain Web3 & Decentralized Tech
emmaThompson07
A
license
C
quality
D
maintenance
Enables AI agents to interact with cryptocurrency ecosystems through wallet management, trading operations (swaps, DCA, limit orders), staking, and multi-chain support starting with Solana.
Updated a year ago (2025-09-26 02:22 UTC)
37
GPL 3.0
remit.md MCP Server
Finance Autonomous Agents Blockchain
pay-skill
A
license
Not graded
quality
F
maintenance
Enables AI agents to perform financial transactions such as direct payments, escrows, and bounty management using natural language with zero code integration. It provides a comprehensive suite of tools for fund streaming, subscriptions, and reputation tracking to facilitate secure agent-to-agent commerce.
Updated 5 months ago (2026-04-07 19:51 UTC)
22
MIT
BotWallet MCP Server
Blockchain Finance Autonomous Agents
botwallet-co
A
license
A
quality
D
maintenance
Enables AI agents to manage USDC wallets on Solana, allowing them to send payments, create invoices, and access paid APIs within human-defined spending limits. It uses threshold signatures to provide agents with financial autonomy while ensuring secure oversight and transaction approval.
Updated 5 months ago (2026-04-08 22:04 UTC)
36
23
3
Apache 2.0
BananaCrystal MCP Serverofficial
Payments & Billing Blockchain Autonomous Agents
BananaCrystal
A
license
A
quality
C
maintenance
Provides AI agents with a wallet and autonomous payment capabilities using stablecoins, enabling seamless micropayments and financial operations with under 5-second settlement on Hedera.
Updated 4 months ago (2026-05-18 16:31 UTC)
40
27
4
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mandalito/StealthPay-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

StealthPay MCP

Problem

Solution

What is MCP?

What is a stealth address?

How StealthPay differs from Umbra / Fluidkey

Example use cases

How it works

Quick start

Install

Configure environment

Security Model

Key philosophy

Operator responsibilities (install/deploy)

Current security controls in this repo

Operational recommendations

Add to Claude Code

Tools

Identity

Onboarding & Profile

Sending payments

Receiving payments

Chain support and requirements

ENS requirements

Practical support summary

Programmable payment profile

Announcement metadata format

Testing

Get Sepolia testnet ETH

Architecture

Local Helpers (.local/)

Standards

Dependencies

Known limitations

Future improvements

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

BananaCrystal MCP Serverofficial

Latest Blog Posts

MCP directory API

Local Helpers (`.local/`)