Skip to main content
Glama

Name Whisper — ENS Intelligence Layer

by ai.namewhisper

renew_ens_name

Destructive

Renew an ENS name or batch of names. Returns the transaction data needed to extend registration.

Unlike registration, renewal is simple — just one transaction with payment. No commit/reveal needed.

Accepts any duration from 1 day up — days, weeks, months, years. ENS protocol has no minimum renewal period; this tool floors at 1 day for safety. Examples: 1 day, 7 days (1 week), 28 days (1 month), 365 days (1 year).

Anyone can renew any name (you don't need to be the owner). This is useful for:

  • Extending your own names before expiry

  • Gifting renewal to a friend's name

  • Protecting valuable names from expiring

Returns exact on-chain pricing from the ETHRegistrarController with a 5% buffer (excess is refunded) — do NOT estimate renewal prices yourself.

For batch renewals (multiple names), all names are bundled into a SINGLE Multicall3 transaction.

Calling this tool never spends money — it only builds an unsigned transaction rendered as a sign-card; nothing happens until the user clicks Sign. So the sign-card IS the confirmation step.

Conversational flow:

  • User names the specific name(s) ("renew coffee.eth", "renew coffee.eth for 3 months"): call this tool IMMEDIATELY. If no duration was given, use the 1-year default and say so ("built it for 1 year — tell me if you want longer/shorter") — do NOT stop to ask the duration first; they can just say a different one and you rebuild.

  • Open-ended "renew my names" / "bulk renew" with no list: first call get_wallet_portfolio to find the names, IGNORE every EXPIRED and PREMIUM_AUCTION name (renewing those reverts the whole batch), present a numbered list grouped by urgency, and ask which names + what duration. Only THEN call this tool.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
namesYesENS name or array of names to renew (e.g. "coffee.eth" or ["coffee.eth", "wallet.eth"])
yearsNoDEPRECATED — use duration instead. Number of years (converted to days internally).
durationNoDuration in days to extend registration (e.g. 7 for 1 week, 28 for a month, 365 for a year). Default: 365. Minimum: 1 day. Maximum: 36500 (100 years).

TDQS

A4.8/5.0
Behavior5/5

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

Discloses that the tool only builds an unsigned transaction (no spending), that the sign-card is the confirmation step, and that batch uses a single Multicall3 transaction. Also mentions 5% buffer on pricing. This adds critical context beyond annotations, which mark destructiveHint=true but description clarifies safety.

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?

Description is well-structured into sections but somewhat long. Every sentence adds value, particularly the conversational flow and guidelines. Could be slightly more concise, but front-loading is effective.

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?

Covers all relevant aspects: return type (transaction data, sign-card), pricing behavior, batch bundling, edge cases (expired/premium names), and integration with other tools. No output schema exists, so description fully compensates.

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% with descriptions. Description adds value by explaining years is deprecated, giving examples for duration (1 day, 7 days, etc.), stating default 365 days, and clarifying names can be string or array. This goes beyond schema.

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 renews an ENS name or batch of names and returns transaction data. It distinguishes from registration by noting simplicity and no commit/reveal. The verb 'renew' and resource 'ENS name' are explicit.

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?

Extensive guidelines: when to call immediately (specific names given) vs when to first call get_wallet_portfolio (open-ended requests). Includes instructions to ignore expired/premium names in batch and not to ask duration first. Explicitly names alternative tool and conversational flow.

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation4/5

Most tools have clearly distinct purposes with detailed descriptions, but some pairs (e.g., search_ens_names vs enumerate_entities, batch_purchase vs sweep) could cause confusion due to overlapping functionality. The descriptions help differentiate, but the large number of tools increases ambiguity risk.

Naming Consistency5/5

All tool names use consistent snake_case with a verb_noun pattern (e.g., get_name_details, set_ens_records, batch_create_listings). Naming conventions are uniform and predictable, making it easy to infer tool purpose from the name.

Tool Count4/5

With 44 tools, the server is quite comprehensive, covering a wide range of ENS operations. While this exceeds the typical 3-15 tool count, the scope of the domain (marketplace, registration, agent identity, etc.) justifies the number, and tools are well-organized into logical groups.

Completeness5/5

The tool surface covers the full lifecycle of ENS names: registration, renewal, wrapping, transfers, marketplace actions (listings, offers, purchases), record management, subnames, agent identity, and market intelligence. No obvious gaps are present for an ENS intelligence platform.

Resources