Skip to main content
Glama

Name Whisper — ENS Intelligence Layer

by ai.namewhisper
OverviewDiscussionsAdmin

bulk_transfer_ens_names

Destructive

Transfer multiple ENS names in one batch — bulk send.

Wrapped names going to the same recipient move in one transaction; each unwrapped name and unwrapped subname takes its own. Supports up to 20 names per batch.

Automatically detects whether each name is wrapped (NameWrapper/ERC-1155) or unwrapped (BaseRegistrar/ERC-721) and builds the correct transfer call for each.

All names can go to the same recipient or to different recipients — specify a toAddress per name. Each toAddress may be a 0x address OR an ENS name (resolved to its address record automatically); pass what the user gave you and never use get_name_details to resolve a recipient.

Conversational flow for "send all my names" / "transfer my names": first call get_wallet_portfolio to find the names, present the FULL list that will be transferred, confirm the recipient, and get explicit confirmation (this is IRREVERSIBLE). Only THEN call this tool. NEVER auto-transfer without explicit confirmation.

Requirements: fromAddress must currently own ALL names in the batch, and every name must be registered (not expired).

WARNING: This transfers ownership of every name, and it cannot be undone. It moves the names only: each unwrapped name keeps its current manager, so each recipient should sync the manager to themselves (a signer that checks each hand-over on-chain first, such as the Name Whisper terminal, also gets a hand-over transaction per name the sender manages). Resolver records (avatar, addresses, etc.) are unaffected and stay on each name; after transfer, consider bulk_set_records to update ETH address records.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
transfersYesArray of name + recipient pairs. Max 20 per batch. All names must be owned by fromAddress.
fromAddressYesCurrent owner wallet address (must sign the transaction). All names must be owned by this address.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / transfers / items / properties / toAddress / description
      Previous value: -"Recipient wallet address"New value: +"Recipient — a 0x wallet address OR an ENS name (e.g. \"vitalik.eth\"), resolved to its address record automatically"
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the destructiveHint/readOnlyHint/idempotentHint annotations by disclosing the wrapped-vs-unwrapped transaction batching model, automatic detection of token standards, ownership and registration preconditions, and the irreversible loss of ownership. It also explains secondary effects (unwrapped names keep their manager, resolver records stay put, recipients should sync the manager) that an agent could not infer from the 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?

Front-loaded with the core action and batching rules, then requirements, then the warning. It is long but nearly every sentence carries operational information; the only mild redundancy is the irreversibility warning appearing twice (mid-paragraph and again in the WARNING block).

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 destructive, non-idempotent batch tool with no output schema and full schema coverage, the description supplies everything an agent needs: preconditions, confirmation protocol, transaction batching behavior, and follow-up tooling (bulk_set_records). Nothing material is missing.

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 is 3, but the description adds real semantics: toAddress accepts either a 0x address or an ENS name resolved automatically, with the explicit instruction to pass the user's input verbatim rather than resolving via get_name_details. The 20-name batch limit and per-name recipient flexibility are also restated usefully.

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?

States a specific verb and resource ('Transfer multiple ENS names') plus the batching scope ('in one batch'), which cleanly separates it from the singular sibling transfer_ens_name. An agent can identify the operation without opening the schema.

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

Usage Guidelines5/5

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

Explicitly prescribes the conversational flow: call get_wallet_portfolio first, present the full list, confirm the recipient, and get explicit confirmation before calling. It names the trigger phrases ('send all my names' / 'transfer my names') and states NEVER auto-transfer, which is exactly the when-to-use / when-not-to-use guidance needed.

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

All Name Whisper — ENS Intelligence Layer toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources