Skip to main content
Glama

erc721_balanceOf

Check how many ERC721 NFTs a specific address owns from a given smart contract. Use this tool to verify NFT ownership balances on Ethereum networks.

Instructions

Get the number of ERC721 NFTs owned by a specific address. Alternative naming for compatibility with MCP client tests.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tokenAddressYesThe address of the ERC721 contract
ownerAddressYesThe address to check balance for
providerNoOptional. The provider to use. If not provided, the default provider is used.
chainIdNoOptional. The chain ID to use.

Implementation Reference

  • Handler function that implements the core logic of the erc721_balanceOf tool by fetching owned tokens via ethersService and computing the balance as the token count.
    async (params) => {
      try {
        // Get the tokens owned by this address
        const tokens = await ethersService.getERC721TokensOfOwner(
          params.tokenAddress,
          params.ownerAddress,
          false,
          params.provider,
          params.chainId
        );
        
        // The balance is the number of tokens
        const balance = tokens.length.toString();
        
        return {
          content: [{ 
            type: "text", 
            text: `${params.ownerAddress} has ${balance} NFTs from contract ${params.tokenAddress}`
          }]
        };
      } catch (error) {
        return {
          isError: true,
          content: [{ 
            type: "text", 
            text: `Error getting NFT balance: ${error instanceof Error ? error.message : String(error)}`
          }]
        };
      }
    }
  • Registration of the erc721_balanceOf tool on the MCP server, including name, description, input schema, and inline handler function.
    // Client test compatible version - erc721_balanceOf
    server.tool(
      "erc721_balanceOf",
      "Get the number of ERC721 NFTs owned by a specific address. Alternative naming for compatibility with MCP client tests.",
      {
        tokenAddress: contractAddressSchema.describe("The address of the ERC721 contract"),
        ownerAddress: addressSchema.describe("The address to check balance for"),
        provider: providerSchema.describe("Optional. The provider to use. If not provided, the default provider is used."),
        chainId: chainIdSchema.describe("Optional. The chain ID to use.")
      },
      async (params) => {
        try {
          // Get the tokens owned by this address
          const tokens = await ethersService.getERC721TokensOfOwner(
            params.tokenAddress,
            params.ownerAddress,
            false,
            params.provider,
            params.chainId
          );
          
          // The balance is the number of tokens
          const balance = tokens.length.toString();
          
          return {
            content: [{ 
              type: "text", 
              text: `${params.ownerAddress} has ${balance} NFTs from contract ${params.tokenAddress}`
            }]
          };
        } catch (error) {
          return {
            isError: true,
            content: [{ 
              type: "text", 
              text: `Error getting NFT balance: ${error instanceof Error ? error.message : String(error)}`
            }]
          };
        }
      }
    );
  • Input schema definition for the erc721_balanceOf tool parameters: tokenAddress, ownerAddress, provider, chainId.
      tokenAddress: contractAddressSchema.describe("The address of the ERC721 contract"),
      ownerAddress: addressSchema.describe("The address to check balance for"),
      provider: providerSchema.describe("Optional. The provider to use. If not provided, the default provider is used."),
      chainId: chainIdSchema.describe("Optional. The chain ID to use.")
    },
Behavior2/5

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

No annotations are provided, so the description carries full burden. It states it's a read operation ('Get'), but doesn't disclose behavioral traits like authentication needs, rate limits, error conditions, or what the return value looks like (e.g., integer count). For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.

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?

Two sentences with zero waste. The first sentence directly states the purpose, and the second adds useful context about naming compatibility. It's appropriately sized and front-loaded with the core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description is incomplete for a tool that likely returns a numeric value. It covers the basic purpose but lacks information about return format, error handling, or dependencies. For a read-only tool with rich schema but no output schema, it should ideally describe what the agent can expect as a result.

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 description coverage is 100%, so the schema already documents all 4 parameters thoroughly with patterns and descriptions. The description doesn't add any parameter semantics beyond what's in the schema, such as explaining relationships between parameters or usage examples. Baseline 3 is appropriate when schema does the heavy lifting.

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 ('Get the number') and resource ('ERC721 NFTs owned by a specific address'), distinguishing it from sibling tools like erc20_balanceOf, getNFTInfo, or getNFTOwner. It explicitly identifies the ERC721 token type and balance-checking function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for checking NFT balances but doesn't explicitly state when to use this tool versus alternatives like erc1155_balanceOf, getNFTInfo, or getNFTOwner. It mentions 'Alternative naming for compatibility' which hints at context but doesn't provide clear when/when-not guidance or named alternatives for similar functionality.

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/crazyrabbitLTC/mcp-ethers-server'

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