Skip to main content
Glama

wallet_get_address

Retrieve the wallet address from a provided private key, mnemonic, or JSON. Automatically uses the PRIVATE_KEY environment variable if no input is given.

Instructions

Get the wallet address

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
walletNoThe wallet (private key, mnemonic, or JSON). If not provided, uses PRIVATE_KEY environment variable if set.

Implementation Reference

  • The core handler function for 'wallet_get_address' that fetches the wallet using the getWallet helper and returns its address.
    export const getAddressHandler = async (input: any): Promise<ToolResultSchema> => {
      try {
        const wallet = await getWallet(input.wallet);
    
        return createSuccessResponse(
        `Wallet address retrieved successfully:
          Address: ${wallet.address}
        `);
      } catch (error) {
        return createErrorResponse(`Failed to get wallet address: ${(error as Error).message}`);
      }
    };
  • Input schema definition for the wallet_get_address tool in the tools array.
      name: "wallet_get_address",
      description: "Get the wallet address",
      inputSchema: {
        type: "object",
        properties: {
          wallet: { type: "string", description: "The wallet (private key, mnemonic, or JSON). If not provided, uses PRIVATE_KEY environment variable if set." }
        },
        required: []
      }
    },
  • src/tools.ts:567-567 (registration)
    Registration of the getAddressHandler function to the 'wallet_get_address' tool name in the handlers dictionary.
    "wallet_get_address": getAddressHandler,
  • Supporting utility getWallet that constructs the ethers.Wallet from input string (private key, mnemonic, or encrypted JSON), connects to provider, and handles env var fallback. Critical for the handler's logic.
    export const getWallet = async (
      walletData?: string, 
      password?: string,
    ): Promise<ethers.Wallet> => {
      const provider = getProvider()
      // If walletData is not provided, check for PRIVATE_KEY environment variable
      if (!walletData && process.env.PRIVATE_KEY) {
        const wallet = new ethers.Wallet(process.env.PRIVATE_KEY);
        return provider ? wallet.connect(provider) : wallet;
      }
      
      // If no walletData and no environment variable, throw an error
      if (!walletData) {
        throw new Error("Wallet data is required or set PRIVATE_KEY environment variable");
      }
      
      try {
        // Try to parse as JSON first
        if (walletData.startsWith("{")) {
          if (!password) {
            throw new Error("Password is required for encrypted JSON wallets");
          }
          
          const wallet = await ethers.Wallet.fromEncryptedJson(walletData, password);
          return provider ? wallet.connect(provider) : wallet;
        }
        
        // Check if it's a mnemonic (12, 15, 18, 21, or 24 words)
        const words = walletData.trim().split(/\s+/);
        if ([12, 15, 18, 21, 24].includes(words.length)) {
          const wallet = ethers.Wallet.fromMnemonic(walletData);
          return provider ? wallet.connect(provider) : wallet;
        }
        
        // Assume it's a private key
        const wallet = new ethers.Wallet(walletData);
        return provider ? wallet.connect(provider) : wallet;
      } catch (error) {
        throw new Error(`Invalid wallet data: ${(error as Error).message}`);
      }
    };
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get the wallet address' implies a read-only operation, but it doesn't specify what happens if the wallet parameter is invalid, whether authentication is needed, or what the output format might be. It mentions the PRIVATE_KEY environment variable fallback in the schema, but the description itself lacks this critical behavioral detail, leaving gaps in understanding how the tool behaves in different scenarios.

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 extremely concise at just three words, with zero wasted language. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place, though this conciseness comes at the cost of completeness in other dimensions.

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 tool's moderate complexity (involving wallet operations with a parameter) and the absence of both annotations and an output schema, the description is incomplete. It doesn't explain what a 'wallet address' means in this context, what format it returns, or how errors are handled. For a financial/cryptographic tool with potential security implications, more context is needed to use it effectively.

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

Parameters3/5

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

The description adds no parameter semantics beyond what's already in the schema, which has 100% coverage. The schema fully describes the single optional parameter 'wallet' and its fallback behavior. Since schema coverage is high, the baseline score is 3, as the description doesn't need to compensate but also doesn't add value beyond the structured data.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get the wallet address' clearly states the action (get) and resource (wallet address), but it's vague about what exactly is being retrieved. It doesn't distinguish from sibling tools like wallet_get_public_key or wallet_get_private_key, which also retrieve wallet-related information. The purpose is understandable but lacks specificity about the type of address being retrieved.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like wallet_get_public_key (which might return similar information) or explain why one would choose this tool over others. There's no context about prerequisites or typical use cases, leaving the agent to infer usage from the tool name alone.

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

Related 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/dcSpark/mcp-cryptowallet-evm'

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