Skip to main content
Glama

fund_account

Add APT tokens to an Aptos testnet account using the faucet for blockchain testing and development purposes.

Instructions

Fund an Aptos account using the testnet faucet. This is only available on testnet and is used to add APT tokens to an account for testing purposes. Returns the funding transaction details.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
account_addressYesAptos account address to fund, e.g., 0x1 or 0x742d35Cc6634C0532925a3b8D6Ac0C4db9c8b3
amountNoAmount of APT to fund (optional, defaults to 1 APT)

Implementation Reference

  • The main handler function for the 'fund_account' tool. It validates input arguments using isFundAccountArgs, calls performFundAccount to execute the funding, and returns a formatted success or error response.
    export async function fundAccountHandler(args: Record<string, any> | undefined) {
      if (!isFundAccountArgs(args)) {
        throw new Error("Invalid arguments for fund_account");
      }
    
      const { account_address, amount = 1 } = args;
    
      try {
        const results = await performFundAccount(account_address, amount);
        return {
          content: [{ type: "text", text: results }],
          isError: false,
        };
      } catch (error) {
        return {
          content: [
            {
              type: "text",
              text: `Error funding account: ${error instanceof Error ? error.message : String(error)}`,
            },
          ],
          isError: true,
        };
      }
    }
  • The Tool definition object for 'fund_account', including name, description, and input schema for validation.
    export const FUND_ACCOUNT: Tool = {
      name: "fund_account",
      description: "Fund an Aptos account using the testnet faucet. This is only available on testnet and is used to add APT tokens to an account for testing purposes. Returns the funding transaction details.",
      inputSchema: {
        type: "object",
        properties: {
          account_address: {
            type: "string",
            description: "Aptos account address to fund, e.g., 0x1 or 0x742d35Cc6634C0532925a3b8D6Ac0C4db9c8b3",
          },
          amount: {
            type: "number",
            description: "Amount of APT to fund (optional, defaults to 1 APT)",
            default: 1,
          },
        },
        required: ["account_address"],
      },
    };
  • Core helper function that performs the actual account funding using Aptos client faucet, handles testnet check, amount conversion, and error cases with specific messages.
    export async function performFundAccount(accountAddress: string, amount: number = 1): Promise<string> {
      try {
        if (!isTestnet()) {
          throw new Error("Account funding is only available on testnet");
        }
    
        const aptos = getAptosClient();
        
        // Convert APT to Octas (1 APT = 10^8 Octas)
        const amountOctas = Math.floor(amount * 100000000);
        
        // Fund the account using the faucet
        const txns = await aptos.fundAccount({
          accountAddress,
          amount: amountOctas,
        });
    
        // Get the first transaction hash
        const txHash = Array.isArray(txns) ? txns[0] : txns;
    
        return `Account Funding Successful:
    Account: ${formatAddress(accountAddress)}
    Amount: ${amount} APT (${amountOctas} Octas)
    Transaction Hash: ${txHash}
    
    ✅ Account has been funded and is ready for transactions!`;
      } catch (error) {
        console.error('Error funding account:', error);
        
        if (error instanceof Error) {
          if (error.message.includes('faucet')) {
            throw new Error("Faucet service is unavailable. Please try again later or use a different faucet.");
          }
          if (error.message.includes('rate limit')) {
            throw new Error("Faucet rate limit exceeded. Please wait before requesting more funds.");
          }
        }
        
        throw new Error(`Failed to fund account: ${error instanceof Error ? error.message : String(error)}`);
      }
    }
  • src/index.ts:37-57 (registration)
    Registration of the FUND_ACCOUNT tool in the pre-defined TOOLS_LIST array used for listTools requests in the main stdio server.
    const TOOLS_LIST = [
      // Account tools
      CREATE_ACCOUNT,
      GET_ACCOUNT_INFO,
      FUND_ACCOUNT,
    
      // Native APT tools
      GET_APT_BALANCE,
      TRANSFER_APT,
    
      // Coin tools
      GET_COIN_BALANCE,
      TRANSFER_COIN,
      DEPLOY_COIN,
      MINT_COIN,
      REGISTER_COIN,
    
      // Transaction tools
      GET_TRANSACTION_STATUS,
      GET_ACCOUNT_TRANSACTIONS,
    ];
  • Registration of the FUND_ACCOUNT tool in the tools list for ListToolsRequestSchema handler in the HTTP server.
    mcpServer.setRequestHandler(ListToolsRequestSchema, async () => ({
      tools: [
        CREATE_ACCOUNT,
        GET_ACCOUNT_INFO,
        FUND_ACCOUNT,
        GET_APT_BALANCE,
        TRANSFER_APT,
        GET_COIN_BALANCE,
        TRANSFER_COIN,
        GET_TRANSACTION_STATUS,
        GET_ACCOUNT_TRANSACTIONS,
      ],
    }));
Behavior4/5

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

With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it's a write operation ('Fund'), specifies the network constraint ('only available on testnet'), and describes the return value ('transaction details'). It could improve by mentioning rate limits or authentication needs, but covers essential context.

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 appropriately sized and front-loaded, with three concise sentences that each earn their place: the first states the action, the second adds constraints and purpose, and the third specifies the return value, with zero wasted words.

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 tool's moderate complexity (a write operation with two parameters), no annotations, and no output schema, the description is mostly complete: it covers purpose, constraints, and return values. It could be more complete by detailing error cases or transaction specifics, but it adequately supports agent usage.

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 schema description coverage is 100%, so the schema already fully documents both parameters. The description does not add any additional meaning beyond what the schema provides, such as explaining APT token units or address formats, meeting the baseline for high coverage.

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 clearly states the specific action ('Fund an Aptos account'), resource ('using the testnet faucet'), and purpose ('to add APT tokens to an account for testing purposes'), distinguishing it from siblings like transfer_apt or mint_coin by specifying the faucet mechanism and testnet-only context.

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?

The description provides clear context for when to use this tool ('only available on testnet', 'for testing purposes'), but does not explicitly state when not to use it or name alternatives like transfer_apt for mainnet or other funding methods, leaving some implicit guidance.

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/punkpeye/aptos-mcp'

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