Skip to main content
Glama
Sign In

Name Whisper — ENS Intelligence Layer

by ai.namewhisper
OverviewDiscussionsAdmin

bulk_register

Destructive

Register multiple ENS names in bulk — total 2 transactions (multiCommit + multiRegister) via NWBulkRegistrar.

Much cheaper and faster than registering names one at a time. Supports up to 20 names per batch.

Flow: multiCommit (1 tx, all N commitments) → wait 60 seconds → multiRegister (1 tx with total ETH for all N names). Excess ETH is refunded.

On v1 the batch shares one secret across all names (every name is revealed in the same multiRegister transaction, so no reveal exposes another name's commitment). All names must be available for registration.

After registration, use bulk_set_records to configure all names at once with addresses, text records, and content hashes.

Once ENS has moved to v2 the result has type "ens_v2_registration" instead: paid in USDC or DAI (never ETH), steps commit (one tx for all names) → approve (if needed) → wait 60s → register. Through Name Whisper's ENS v2 router (feeMode "atomic") one register tx covers every name and carries the Name Whisper fee (1%, same token) in that same transaction; otherwise there is one register per name, each name has its own secret (so one register reveals nothing about the others), and the fee is a separate last transaction, sent only after the registrations go through. Follow the result's message: quote the total once in the token, as the result shows it (e.g. 8.09 USDC), with the Name Whisper fee as included in it.

Input Schema

NameRequiredDescriptionDefault
namesYesArray of ENS names to register (e.g. ["coffee.eth", "tea.eth"]). Max 20 per batch.
durationNoRegistration duration in days, applied to every name in the batch. ENS protocol minimum is 28 days; maximum is 3650 (10 years); default is 365 (1 year).
fromAddressNoENS v2 only: the wallet that signs and pays in USDC/DAI, when it is not walletAddress (registering to another wallet). Defaults to walletAddress.
paymentTokenNoENS v2 only: the stablecoin symbol or address explicitly chosen by the user. Otherwise omit: defaults to the first USDC-family token accepted by the active router (MOCKUSDC on Sepolia; Circle USDC is not accepted there), then DAI, then other accepted tokens. Do not choose based on wallet balances. Ignored while ENS v1 registration is open, which is paid in ETH.
durationYearsNoDEPRECATED — use duration (days) instead. Number of years (converted to days internally).
walletAddressYesWallet address that will own all registered names

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / fromAddress
      Added value: +{
+  "description": "ENS v2 only: the wallet that signs and pays in USDC/DAI, when it is not walletAddress (registering to another wallet). Defaults to walletAddress.",
+  "type": "string"
+}
    • addedInput schema / properties / paymentToken
      Added value: +{
+  "description": "ENS v2 only: the stablecoin symbol or address explicitly chosen by the user. Otherwise omit: defaults to the first USDC-family token accepted by the active router (MOCKUSDC on Sepolia; Circle USDC is not accepted there), then DAI, then other accepted tokens. Do not choose based on wallet balances. Ignored while ENS v1 registration is open, which is paid in ETH.",
+  "type": "string"
+}
  2. Changed3 schema fields changed
    • addedInput schema / properties / duration
      Added value: +{
+  "default": 365,
+  "description": "Registration duration in days, applied to every name in the batch. ENS protocol minimum is 28 days; maximum is 3650 (10 years); default is 365 (1 year).",
+  "maximum": 3650,
+  "minimum": 28,
+  "type": "integer"
+}
    • removedInput schema / properties / durationYears / default
      Removed value: -1
    • changedInput schema / properties / durationYears / description
      Previous value: -"Registration duration in years (same for all names, default: 1)"New value: +"DEPRECATED — use duration (days) instead. Number of years (converted to days internally)."
  3. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations (destructiveHint/readOnlyHint only say it is a non-idempotent write). It discloses the exact transaction sequence, the 60-second wait, that excess ETH is refunded, that v1 shares one secret so no reveal exposes another name, and that v2 charges a 1% Name Whisper fee in the payment token with an approve step. These are precisely the behavioral traits an agent needs before invoking an irreversible, fund-spending operation.

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

Conciseness3/5

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

The critical facts are front-loaded (2 transactions, cheaper, max 20 names), but the v2 paragraph is a dense run-on covering fee modes, per-name secrets, and a separate fee transaction, followed by a quoting instruction that reads as prompt text rather than tool documentation. Roughly half the length is a branch most agents will never hit, which dilutes scannability.

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?

With no output schema and six parameters, the description carries the burden well: it describes the result's dual shape (v1 vs v2 'ens_v2_registration'), the success path, the refund behavior, and the mandatory post-step. An agent has enough to call it and to interpret what comes back without further documentation.

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 cross-parameter semantics the schema does not: paymentToken is conditioned on v1-vs-v2 mode (v1 always ETH), the 1% fee lives in that same token, and fromAddress matters only when paying from a different wallet. It also explains how the ETH total is aggregated across the names array and refunded.

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 (register multiple ENS names in bulk) plus the concrete mechanism (2 transactions via NWBulkRegistrar). It explicitly contrasts with the sibling pattern of registering one at a time and points to bulk_set_records as the follow-up, so an agent can place it against the other 44 tools without opening a schema.

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?

Gives clear selection context: use this because it is 'much cheaper and faster than registering names one at a time', states the precondition that all names must be available, and names the follow-up tool (bulk_set_records). It stops short of naming the single-registration sibling (e.g. purchase_name / manage_ens_name) as the explicit alternative, so the routing is implied rather than fully enumerated.

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