Skip to main content
Glama
monostate

Crossmint HR Airdrop MCP

by monostate

add_liquidity

Enhance liquidity pools by adding specified amounts of tokens and SOL. Supports HR teams in managing token airdrops for employees with automated processes.

Instructions

Add liquidity to the created token

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
solAmountYesAmount of SOL to add to liquidity pool
tokenAmountYesAmount of tokens to add to liquidity pool

Implementation Reference

  • src/server.ts:185-202 (registration)
    Registration of the 'add_liquidity' tool in the MCP server's tool list, including name, description, and input schema.
    {
      name: 'add_liquidity',
      description: 'Add liquidity to the created token',
      inputSchema: {
        type: 'object',
        properties: {
          tokenAmount: {
            type: 'number',
            description: 'Amount of tokens to add to liquidity pool',
          },
          solAmount: {
            type: 'number',
            description: 'Amount of SOL to add to liquidity pool',
          },
        },
        required: ['tokenAmount', 'solAmount'],
      },
    },
  • The primary handler for the 'add_liquidity' MCP tool. Validates arguments using Zod, checks connected wallet and created token prerequisites, simulates liquidity provision by deducting SOL from state balance, and returns formatted success response.
      private async handleAddLiquidity(args: any) {
        if (!this.state.connectedWallet) {
          throw new McpError(
            ErrorCode.InvalidRequest,
            'No wallet connected. Please connect a wallet first.'
          );
        }
    
        if (!this.state.createdToken) {
          throw new McpError(
            ErrorCode.InvalidRequest,
            'No token created. Please create a token first.'
          );
        }
    
        // Validate input
        const schema = z.object({
          tokenAmount: z.number().positive(),
          solAmount: z.number().positive(),
        });
        
        const { tokenAmount, solAmount } = schema.parse(args);
        
        // Check if we have enough balance
        if (this.state.connectedWallet.solBalance < solAmount) {
          throw new McpError(
            ErrorCode.InvalidRequest,
            `Insufficient SOL balance. You have ${this.state.connectedWallet.solBalance} SOL, but ${solAmount} SOL is required.`
          );
        }
        
        // In a real implementation, we would call the Raydium liquidity addition function
        // For this demo, we'll simulate liquidity addition
        
        // Update SOL balance
        this.state.connectedWallet.solBalance -= solAmount;
        
        return {
          content: [
            {
              type: 'text',
              text: `
    Liquidity added successfully:
    Token: ${this.state.createdToken.symbol}
    Token Amount: ${tokenAmount.toLocaleString()} ${this.state.createdToken.symbol}
    SOL Amount: ${solAmount} SOL
    Remaining SOL Balance: ${this.state.connectedWallet.solBalance} SOL
    
    Next step: Generate wallets for employees.
              `.trim(),
            },
          ],
        };
      }
  • Utility helper function to add liquidity for a token mint. Creates associated token account if needed and sends transaction (simplified simulation). Imported in server.ts and tokenUtils.ts but not called in the MCP handler.
    export async function addLiquidity(
      connection: Connection,
      payer: Keypair,
      mintAddress: string,
      tokenAmount: number,
      solAmount: number
    ): Promise<{ txId: string }> {
      try {
        console.log(`Adding liquidity: ${tokenAmount} tokens + ${solAmount} SOL`);
        
        // Convert mintAddress string to PublicKey
        const mintPublicKey = new PublicKey(mintAddress);
        
        // Create a transaction
        const transaction = new Transaction();
        
        // Get the associated token account for the payer
        const tokenAccount = await getAssociatedTokenAddress(
          mintPublicKey,
          payer.publicKey
        );
        
        // Check if the token account exists
        try {
          await getAccount(connection, tokenAccount);
        } catch (error) {
          // If the token account doesn't exist, create it
          transaction.add(
            createAssociatedTokenAccountInstruction(
              payer.publicKey,
              tokenAccount,
              payer.publicKey,
              mintPublicKey
            )
          );
        }
        
        // In a real implementation, this would interact with a DEX like Raydium
        // For now, we'll just simulate the liquidity addition by transferring tokens
        // to a "liquidity pool" (which is just the payer's account in this simulation)
        
        // Send the transaction
        const signature = await sendAndConfirmTransaction(
          connection,
          transaction,
          [payer]
        );
        
        console.log(`Liquidity added with transaction ID: ${signature}`);
        
        return {
          txId: signature
        };
      } catch (error: any) {
        console.error('Error adding liquidity:', error);
        throw new Error(`Liquidity addition failed: ${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. It states the action ('add liquidity') but lacks details on permissions required, whether it's a mutating operation (implied by 'add'), potential costs, rate limits, or what happens upon success/failure. For a financial tool with zero annotation coverage, this is a significant gap in transparency.

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 that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with zero waste.

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 financial liquidity operation, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'liquidity' entails in this context, what the tool returns, or any side effects. The schema covers parameters well, but overall context for safe and effective use is lacking.

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 input schema has 100% description coverage, with clear parameter descriptions (e.g., 'Amount of SOL to add to liquidity pool'). The tool description adds no additional meaning beyond what the schema provides, such as explaining parameter relationships or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.

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 states the action ('add liquidity') and target ('created token'), which provides a basic purpose. However, it's vague about what 'created token' refers to (presumably a token created via the sibling 'create_token' tool) and doesn't distinguish this from other liquidity-related tools (none exist in siblings, but clarity is still limited). It avoids tautology by specifying the action beyond just the name.

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 prerequisites (e.g., needing a created token first, possibly via 'create_token'), exclusions, or contextual triggers. It's a standalone statement with no 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

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/monostate/Employees-Airdrop-Rewards-MCP'

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