Skip to main content
Glama

Trade coin

zora_trade_coin

Swap ETH or ERC20 tokens for other coins on the Zora Coins ecosystem using permit2 authorization where available. Execute trades through a standardized interface on Base mainnet.

Instructions

Swap ETH or ERC20 for a coin (or back). Uses permit2 for ERC20 where supported. Requires PRIVATE_KEY (EOA).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sellTypeYes
sellAddressNo
sellDecimalsNo
buyTypeYes
buyAddressNo
amountYes
slippageNo
recipientNo
senderNo

Implementation Reference

  • src/index.ts:432-490 (registration)
    Registration of the 'zora_trade_coin' MCP tool, including inline schema definition and handler function that orchestrates the trade using CoinsSDK.
    server.registerTool(
      "zora_trade_coin",
      {
        title: "Trade coin",
        description:
          "Swap ETH or ERC20 for a coin (or back). Uses permit2 for ERC20 where supported. Requires PRIVATE_KEY (EOA).",
        inputSchema: {
          sellType: z.enum(["eth", "erc20"]),
          sellAddress: z.string().optional(),     // required if sellType = erc20
          sellDecimals: z.number().int().min(0).max(36).optional(), // required if sellType = erc20
          buyType: z.enum(["eth", "erc20"]),
          buyAddress: z.string().optional(),      // required if buyType = erc20
          amount: z.string().min(1),              // human-readable, e.g., "0.001" ETH or "4" USDC
          slippage: z.number().min(0).max(0.99).default(0.05).optional(),
          recipient: z.string().optional(),
          sender: z.string().optional(),
        },
      },
      async (args) => {
        ensureWallet();
        const {
          sellType,
          sellAddress,
          sellDecimals,
          buyType,
          buyAddress,
          amount,
          slippage,
          recipient,
          sender,
        } = args;
    
        const amountIn =
          sellType === "eth"
            ? parseEther(amount)
            : parseUnits(
                amount,
                typeof sellDecimals === "number" ? sellDecimals : 18
              );
    
        const tradeParameters: any = {
          sell: sellType === "eth" ? { type: "eth" } : { type: "erc20", address: sellAddress },
          buy: buyType === "eth" ? { type: "eth" } : { type: "erc20", address: buyAddress },
          amountIn,
          slippage: typeof slippage === "number" ? slippage : 0.05,
          sender: sender || account!.address,
          recipient: recipient || account!.address,
        };
    
        const receipt = await CoinsSDK.tradeCoin({
          tradeParameters,
          walletClient: walletClient!,
          account: account!,
          publicClient,
        });
    
        return { content: [{ type: "text", text: json(receipt) }] };
      }
    );
  • The core handler logic for executing the 'zora_trade_coin' tool. Parses input amounts, constructs trade parameters, ensures wallet is set up, calls external CoinsSDK.tradeCoin, and formats the response.
    async (args) => {
      ensureWallet();
      const {
        sellType,
        sellAddress,
        sellDecimals,
        buyType,
        buyAddress,
        amount,
        slippage,
        recipient,
        sender,
      } = args;
    
      const amountIn =
        sellType === "eth"
          ? parseEther(amount)
          : parseUnits(
              amount,
              typeof sellDecimals === "number" ? sellDecimals : 18
            );
    
      const tradeParameters: any = {
        sell: sellType === "eth" ? { type: "eth" } : { type: "erc20", address: sellAddress },
        buy: buyType === "eth" ? { type: "eth" } : { type: "erc20", address: buyAddress },
        amountIn,
        slippage: typeof slippage === "number" ? slippage : 0.05,
        sender: sender || account!.address,
        recipient: recipient || account!.address,
      };
    
      const receipt = await CoinsSDK.tradeCoin({
        tradeParameters,
        walletClient: walletClient!,
        account: account!,
        publicClient,
      });
    
      return { content: [{ type: "text", text: json(receipt) }] };
    }
  • Zod input schema for the 'zora_trade_coin' tool, validating parameters for selling ETH/ERC20 to buy coin or vice versa, including slippage and addresses.
    {
      title: "Trade coin",
      description:
        "Swap ETH or ERC20 for a coin (or back). Uses permit2 for ERC20 where supported. Requires PRIVATE_KEY (EOA).",
      inputSchema: {
        sellType: z.enum(["eth", "erc20"]),
        sellAddress: z.string().optional(),     // required if sellType = erc20
        sellDecimals: z.number().int().min(0).max(36).optional(), // required if sellType = erc20
        buyType: z.enum(["eth", "erc20"]),
        buyAddress: z.string().optional(),      // required if buyType = erc20
        amount: z.string().min(1),              // human-readable, e.g., "0.001" ETH or "4" USDC
        slippage: z.number().min(0).max(0.99).default(0.05).optional(),
        recipient: z.string().optional(),
        sender: z.string().optional(),
      },
    },
Behavior3/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. It adds some context: it mentions 'Uses permit2 for ERC20 where supported' (a technical detail) and 'Requires PRIVATE_KEY (EOA)' (an authentication requirement). However, it lacks critical behavioral traits like whether this is a read-only or destructive operation, potential rate limits, error handling, or what the tool returns, which are significant gaps for a trading tool.

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 and front-loaded, consisting of just two sentences that directly convey key information without any wasted words. Every sentence earns its place by stating the core action and important constraints.

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 of a trading tool with 9 parameters, no annotations, and no output schema, the description is incomplete. It misses essential details like the tool's behavioral impact (e.g., whether it executes trades destructively), expected return values, error conditions, and comprehensive parameter explanations, making it inadequate for safe and effective use by an AI agent.

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?

The schema description coverage is 0%, meaning none of the 9 parameters are documented in the schema. The description adds minimal parameter semantics: it implies parameters for 'ETH or ERC20' (relating to sellType/buyType) and 'swap' (relating to amount), but doesn't explain the purpose or usage of most parameters like sellAddress, sellDecimals, slippage, recipient, or sender. This insufficiently compensates for the lack of schema documentation.

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 action ('Swap ETH or ERC20 for a coin or back') and identifies the resource (coins), making the purpose specific. However, it doesn't explicitly differentiate from sibling tools like 'zora_get_coin_swaps' or 'zora_explore_last_traded', which might involve similar trading concepts, so it doesn't reach the highest score.

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 mentions a prerequisite ('Requires PRIVATE_KEY (EOA)'), but doesn't explain when to choose this over other trading-related tools or what scenarios it's best suited for, leaving the agent without clear usage context.

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/r4topunk/zora-coins-mcp-server'

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