Skip to main content
Glama

encode_calldata

Encodes EVM function calls into calldata hex for smart contract interactions. Provide ABI fragments, function name, and arguments to generate callable data and function selectors.

Instructions

Encode EVM function call into calldata hex. Provide ABI fragment array, function name, and arguments. Returns hex calldata and function selector for use with call_contract.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
abiYesABI fragment array for the function (JSON array of objects)
functionNameYesFunction name to encode (e.g., "transfer", "approve")
argsNoFunction arguments array (e.g., ["0xAddress", "1000000"]). Omit for zero-arg functions.
wallet_idNoTarget wallet ID. Required for multi-wallet sessions; auto-resolved when session has a single wallet.

Implementation Reference

  • The actual handler function for the `encode_calldata` tool, which performs an API call to encode the calldata.
    async (args) => {
      const body: Record<string, unknown> = {
        abi: args.abi,
        functionName: args.functionName,
        args: args.args ?? [],
      };
      if (args.wallet_id) body.walletId = args.wallet_id;
      const result = await apiClient.post('/v1/utils/encode-calldata', body);
      return toToolResult(result);
    },
  • Input schema validation for the `encode_calldata` tool using Zod.
    {
      abi: z.array(z.record(z.unknown())).describe('ABI fragment array for the function (JSON array of objects)'),
      functionName: z.string().describe('Function name to encode (e.g., "transfer", "approve")'),
      args: z.array(z.any()).optional().describe('Function arguments array (e.g., ["0xAddress", "1000000"]). Omit for zero-arg functions.'),
      wallet_id: z.string().optional().describe('Target wallet ID. Required for multi-wallet sessions; auto-resolved when session has a single wallet.'),
    },
  • Registration function that defines the `encode_calldata` MCP tool.
    export function registerEncodeCalldata(
      server: McpServer,
      apiClient: ApiClient,
      walletContext?: WalletContext,
    ): void {
      server.tool(
        'encode_calldata',
        withWalletPrefix(
          'Encode EVM function call into calldata hex. Provide ABI fragment array, function name, and arguments. Returns hex calldata and function selector for use with call_contract.',
          walletContext?.walletName,
        ),
        {
          abi: z.array(z.record(z.unknown())).describe('ABI fragment array for the function (JSON array of objects)'),
          functionName: z.string().describe('Function name to encode (e.g., "transfer", "approve")'),
          args: z.array(z.any()).optional().describe('Function arguments array (e.g., ["0xAddress", "1000000"]). Omit for zero-arg functions.'),
          wallet_id: z.string().optional().describe('Target wallet ID. Required for multi-wallet sessions; auto-resolved when session has a single wallet.'),
        },
        async (args) => {
          const body: Record<string, unknown> = {
            abi: args.abi,
            functionName: args.functionName,
            args: args.args ?? [],
          };
          if (args.wallet_id) body.walletId = args.wallet_id;
          const result = await apiClient.post('/v1/utils/encode-calldata', body);
          return toToolResult(result);
        },
      );
    }
Behavior3/5

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

No annotations provided, so description carries full burden. It discloses return values (hex calldata and function selector) but omits safety characteristics (this is likely a pure computation with no side effects) and error behaviors (invalid ABI handling, type mismatches).

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?

Extremely efficient: two sentences total. Front-loaded with core action, zero redundancy. Every clause earns its place by defining inputs, outputs, and consumption pattern.

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?

Despite no output schema, description documents return values (hex calldata and selector). With rich input schema (100% coverage, examples) and clear workflow integration mentioned, the definition is complete for a utility encoding function.

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?

Schema has 100% description coverage with examples (e.g., functionName examples, args format). Description maps to these ('Provide ABI fragment array, function name, and arguments') but adds no semantic depth beyond schema definitions. Baseline 3 appropriate for high-coverage schemas.

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?

Description opens with specific verb (Encode), clear resource (EVM function call), and output format (calldata hex). It distinguishes from sibling execution tools like call_contract by emphasizing this is an encoding/preparation step.

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?

Explicitly links output to sibling tool call_contract ('for use with call_contract'), providing clear workflow context. Lacks explicit negative guidance (when not to use vs alternatives like send_token), but the positive workflow guidance is strong.

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/minhoyoo-iotrust/WAIaaS'

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