Skip to main content
Glama

get-ens-address

Retrieve the Ethereum Name Service (ENS) address for a given domain name, enabling blockchain interactions through the MCPilot server.

Instructions

Get the ENS address for name

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
chainIdNo
blockNumberNo

Implementation Reference

  • The main handler function that executes the tool logic: normalizes the ENS name, calls wagmi's getEnsAddress with optional chainId and blockNumber, and returns the address as text content.
    execute: async (args) => {
      const name = args.name
      const chainId = args.chainId as typeof wagmiConfig['chains'][number]['id']
      const blockNumber = args.blockNumber ? BigInt(args.blockNumber) : undefined
      const result = await getEnsAddress(wagmiConfig, {
        name: normalize(name),
        blockNumber,
        chainId,
      })
      return {
        content: [
          {
            type: "text",
            text: result ?? "undefined",
          },
        ],
      }
    },
  • Zod schema defining the input parameters: required 'name' (string), optional 'chainId' and 'blockNumber' (numbers).
    parameters: z.object({
      name: z.string(),
      chainId: z.coerce.number().optional(),
      blockNumber: z.coerce.number().optional(),
    }),
  • The registration function that adds the 'get-ens-address' tool to the FastMCP server, including name, description, schema, and handler.
    export function registerGetENSAddressTools(server: FastMCP): void {
      server.addTool({
        name: "get-ens-address",
        description: "Get the ENS address for name",
        parameters: z.object({
          name: z.string(),
          chainId: z.coerce.number().optional(),
          blockNumber: z.coerce.number().optional(),
        }),
        execute: async (args) => {
          const name = args.name
          const chainId = args.chainId as typeof wagmiConfig['chains'][number]['id']
          const blockNumber = args.blockNumber ? BigInt(args.blockNumber) : undefined
          const result = await getEnsAddress(wagmiConfig, {
            name: normalize(name),
            blockNumber,
            chainId,
          })
          return {
            content: [
              {
                type: "text",
                text: result ?? "undefined",
              },
            ],
          }
        },
      });
    };
  • Top-level call to register the get-ens-address tool during server setup.
    registerGetENSAddressTools(server);
Behavior2/5

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

With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits such as whether this is a read-only operation, potential rate limits, error conditions, or what the output format might be (e.g., Ethereum address string).

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 a single, efficient sentence with no wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.

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

Completeness2/5

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

Given the complexity (3 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't provide enough context for the agent to understand how to use the tool effectively, missing details on parameters, behavior, and output.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'name', 'chainId', or 'blockNumber' mean, their formats (e.g., ENS name string, numeric chain ID), or that 'name' is required while others are optional.

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 verb ('Get') and resource ('ENS address for name'), making the purpose understandable. However, it doesn't differentiate from the sibling tool 'get-ens-name' which presumably does the reverse operation (get name for address), so it misses full sibling distinction.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention the sibling 'get-ens-name' or other related tools like 'get-account', leaving the agent without context for tool selection.

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

Install Server

Other Tools

Latest Blog Posts

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/Xiawpohr/mcpilot'

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