Skip to main content
Glama

azeth_deposit

Deposit ETH or ERC-20 tokens from your external wallet into your Azeth smart account to fund transfers, payments, and operations.

Instructions

Deposit ETH or ERC-20 tokens from your EOA wallet into your own Azeth smart account.

Use this when: Your smart account needs funding for transfers, x402 payments, or other operations.

SECURITY: This verifies ON-CHAIN that the target is a real Azeth smart account owned by you. You cannot deposit to someone else's smart account.

Returns: Transaction hash and deposit details.

Note: If no target account is specified, deposits to your first smart account. For ETH deposits, omit the token parameter. For ERC-20 tokens, provide the token contract address AND decimals. The amount is in human-readable units (e.g., "0.01" for 0.01 ETH, "100" for 100 USDC).

Example: { "amount": "0.01" } or { "amount": "50", "token": "0x036CbD53842c5426634e7929541eC2318f3dCF7e", "decimals": 6 }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainNoTarget chain. Defaults to AZETH_CHAIN env var or "baseSepolia". Accepts "base", "baseSepolia", "ethereumSepolia", "ethereum" (and aliases like "base-sepolia", "eth-sepolia", "sepolia", "eth", "mainnet").
amountYesAmount to deposit in human-readable units (e.g., "0.01" for 0.01 ETH).
tokenNoERC-20 token contract address. Omit for native ETH deposit.
decimalsNoToken decimals for ERC-20 deposits. REQUIRED when token is specified. Use 6 for USDC, 18 for WETH.
smartAccountNoTarget smart account address, name, or "#N" (account index). If omitted, deposits to your first Azeth account.

Implementation Reference

  • The implementation of the azeth_deposit MCP tool, which enables depositing ETH or ERC-20 tokens into a smart account.
    // azeth_deposit
    // ──────────────────────────────────────────────
    server.registerTool(
      'azeth_deposit',
      {
        description: [
          'Deposit ETH or ERC-20 tokens from your EOA wallet into your own Azeth smart account.',
          '',
          'Use this when: Your smart account needs funding for transfers, x402 payments, or other operations.',
          '',
          'SECURITY: This verifies ON-CHAIN that the target is a real Azeth smart account owned by you.',
          'You cannot deposit to someone else\'s smart account.',
          '',
          'Returns: Transaction hash and deposit details.',
          '',
          'Note: If no target account is specified, deposits to your first smart account.',
          'For ETH deposits, omit the token parameter. For ERC-20 tokens, provide the token contract address AND decimals.',
          'The amount is in human-readable units (e.g., "0.01" for 0.01 ETH, "100" for 100 USDC).',
          '',
          'Example: { "amount": "0.01" } or { "amount": "50", "token": "0x036CbD53842c5426634e7929541eC2318f3dCF7e", "decimals": 6 }',
        ].join('\n'),
        inputSchema: z.object({
          chain: z.string().optional().describe('Target chain. Defaults to AZETH_CHAIN env var or "baseSepolia". Accepts "base", "baseSepolia", "ethereumSepolia", "ethereum" (and aliases like "base-sepolia", "eth-sepolia", "sepolia", "eth", "mainnet").'),
          amount: z.string().describe('Amount to deposit in human-readable units (e.g., "0.01" for 0.01 ETH).'),
          token: z.string().optional().describe('ERC-20 token contract address. Omit for native ETH deposit.'),
          decimals: z.coerce.number().int().min(0).max(18).optional()
            .describe('Token decimals for ERC-20 deposits. REQUIRED when token is specified. Use 6 for USDC, 18 for WETH.'),
          smartAccount: z.string().optional()
            .describe('Target smart account address, name, or "#N" (account index). If omitted, deposits to your first Azeth account.'),
        }),
      },
      async (args) => {
        if (args.token && !validateAddress(args.token)) {
          return error('INVALID_INPUT', `Invalid token address: "${args.token}".`, 'Must be 0x-prefixed followed by 40 hex characters.');
        }
        if (args.token && args.decimals === undefined) {
          return error('INVALID_INPUT', 'decimals is required when token address is provided.', 'Use 6 for USDC, 18 for WETH.');
        }
    
        let client;
        try {
          client = await createClient(args.chain);
    
          let target: `0x${string}`;
          if (args.smartAccount) {
            try {
              target = (await resolveSmartAccount(args.smartAccount, client))!;
            } catch (resolveErr) {
              return handleError(resolveErr);
            }
          } else {
            target = await client.resolveSmartAccount();
          }
    
          const decimals = args.decimals ?? 18;
          let amount: bigint;
          try {
            amount = args.token ? parseUnits(args.amount, decimals) : parseEther(args.amount);
          } catch {
            return error('INVALID_INPUT', 'Invalid amount format — must be a valid decimal number.');
          }
    
          const result = await client.deposit({
            to: target,
            amount,
            token: args.token as `0x${string}` | undefined,
          });
    
          return success(
            {
              txHash: result.txHash,
              from: result.from,
              to: result.to,
              amount: args.amount,
              token: result.token,
            },
            { txHash: result.txHash },
          );
        } catch (err) {
          return handleError(err);
        } finally {
          try { await client?.destroy(); } catch (e) { process.stderr.write(`[azeth-mcp] destroy error: ${e instanceof Error ? e.message : String(e)}\n`); }
        }
      },
    );
Behavior4/5

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

With no annotations provided, the description carries full disclosure burden. It covers critical security behavior ('verifies ON-CHAIN that the target is a real Azeth smart account owned by you'), return values ('Transaction hash and deposit details'), and default fallbacks ('deposits to your first smart account'). Missing only gas/confirmation details.

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?

Information-dense and front-loaded with the core action first. Structure follows logical progression: purpose → usage → security → parameters → examples. Lengthy but justified by the complexity of ETH vs ERC-20 handling and security requirements; no sentences are wasted.

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?

Given the complexity (multi-chain, multi-token, cryptographic ownership verification), the description adequately covers prerequisites, security constraints, and return values despite lacking an output schema. Sibling differentiation is implicit but sufficient for selection.

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?

Despite 100% schema coverage, the description adds substantial value through conditional logic: 'omit the token parameter' for ETH, 'provide... AND decimals' for ERC-20, and the amount format clarification ('human-readable units'). The concrete JSON examples provide syntax clarity beyond 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 opens with a precise action statement: 'Deposit ETH or ERC-20 tokens from your EOA wallet into your own Azeth smart account.' It specifies the exact resource types (ETH/ERC-20), source (EOA), and destination (Azeth smart account), clearly distinguishing it from sibling tools like azeth_transfer (likely inter-account) or azeth_pay (payment operations).

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?

Provides explicit 'Use this when' clause linking to specific downstream operations ('funding for transfers, x402 payments'). Includes clear security exclusions ('You cannot deposit to someone else's smart account'). Does not explicitly name sibling alternatives, though the context sufficiently differentiates it from payment/transfer tools.

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/azeth-protocol/mcp-azeth'

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