Skip to main content
Glama

Name Whisper — ENS Intelligence Layer

by ai.namewhisper

transfer_ens_name

Destructive

Transfer ownership of an ENS name to another wallet. Call this tool IMMEDIATELY — as your first and only action — whenever the user asks to transfer/send/move/give a name to someone: "transfer coffee.eth to vitalik.eth", "send myname.eth to 0xabc...". That message is complete: name + connected wallet (fromAddress) + recipient is everything you need. Do not ask for confirmation first, do not call any other tool first.

Calling this tool does NOT move the name. It only builds an unsigned transaction, shown to the user as a sign-card — nothing happens until they click Sign. The sign-card IS the confirmation and the preview, so a "should I go ahead?" reply in chat is always wrong; the right response to a transfer request is this tool call.

Recipient rule (critical): pass toAddress exactly as the user wrote it — a 0x address OR an ENS name like "vitalik.eth". The tool resolves an ENS-name recipient to its on-chain address record itself. NEVER pre-resolve the recipient with get_name_details or any other lookup — get_name_details returns the NFT holder, which is often NOT where the name points, and using it as the destination sends the name to the wrong wallet. Never refuse just because the recipient is a name. If the recipient name has no address record, this tool returns a clear error — relay it and ask for a 0x address.

Handles wrapped (NameWrapper/ERC-1155) and unwrapped (BaseRegistrar/ERC-721) names automatically. Requires: fromAddress currently owns the name; the name is not expired. Transfer moves full ownership (recipient gains complete control); resolver records (avatar, addresses, etc.) are unaffected and stay on the name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesENS name to transfer (e.g. "coffee.eth")
toAddressYesRecipient — either a 0x wallet address OR an ENS name (e.g. "vitalik.eth"). ENS names are resolved to their on-chain address record automatically.
fromAddressYesCurrent owner wallet address (must sign the transaction)

TDQS

A4.8/5.0
Behavior5/5

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

The description adds substantial context beyond annotations: it explains that the tool builds an unsigned transaction ('nothing happens until they click Sign'), handles wrapped and unwrapped names, requires ownership and non-expired status, and states that resolver records remain unaffected. 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.

Conciseness4/5

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

The description is long but well-structured, front-loading the core action and then providing detailed guidance. Every sentence adds value, though some repetition could be trimmed. It earns its length given the complexity.

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 prerequisites, behavior, error handling (e.g., if recipient name has no address record), and what the user sees (sign-card). While it lacks an explicit mention of the return value format, the description is otherwise complete for a tool without an output schema.

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?

Schema coverage is 100%, and the description adds significant meaning: for 'name' it gives an example, for 'toAddress' it explains it can be an ENS name and warns against pre-resolving, and for 'fromAddress' it clarifies the signing requirement. This adds value beyond the 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 'Transfer ownership of an ENS name to another wallet' using a specific verb and resource. It distinguishes itself from siblings like 'bulk_transfer_ens_names' by focusing on a single name transfer and clarifies it only builds an unsigned transaction.

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?

Explicit instructions are given: 'Call this tool IMMEDIATELY — as your first and only action' with examples of user requests. It warns against asking for confirmation or calling other tools first, and includes a critical recipient rule with reasoning. This fully guides when and how to use the tool.

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