Skip to main content
Glama

get_chain_info

Retrieve detailed information about any EVM-compatible network, including Ethereum, Optimism, Arbitrum, and Base. Specify the network name or chain ID using the EVM MCP Server.

Instructions

Get information about an EVM network

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
networkNoNetwork name (e.g., 'ethereum', 'optimism', 'arbitrum', 'base', etc.) or chain ID. Supports all EVM-compatible networks. Defaults to Ethereum mainnet.

Implementation Reference

  • Registers the get_chain_info MCP tool, including input schema (network parameter), annotations, and inline handler that fetches chainId, blockNumber, and rpcUrl using services.
    server.registerTool(
      "get_chain_info",
      {
        description: "Get information about an EVM network: chain ID, current block number, and RPC endpoint",
        inputSchema: {
          network: z.string().optional().describe("Network name (e.g., 'ethereum', 'optimism', 'arbitrum', 'base') or chain ID. Defaults to Ethereum mainnet.")
        },
        annotations: {
          title: "Get Chain Info",
          readOnlyHint: true,
          destructiveHint: false,
          idempotentHint: true,
          openWorldHint: true
        }
      },
      async ({ network = "ethereum" }) => {
        try {
          const chainId = await services.getChainId(network);
          const blockNumber = await services.getBlockNumber(network);
          const rpcUrl = getRpcUrl(network);
    
          return {
            content: [{
              type: "text",
              text: JSON.stringify({ network, chainId, blockNumber: blockNumber.toString(), rpcUrl }, null, 2)
            }]
          };
        } catch (error) {
          return {
            content: [{ type: "text", text: `Error fetching chain info: ${error instanceof Error ? error.message : String(error)}` }],
            isError: true
          };
        }
      }
    );
  • Handler function for get_chain_info tool that orchestrates calls to getChainId, getBlockNumber, and getRpcUrl services.
    async ({ network = "ethereum" }) => {
      try {
        const chainId = await services.getChainId(network);
        const blockNumber = await services.getBlockNumber(network);
        const rpcUrl = getRpcUrl(network);
    
        return {
          content: [{
            type: "text",
            text: JSON.stringify({ network, chainId, blockNumber: blockNumber.toString(), rpcUrl }, null, 2)
          }]
        };
      } catch (error) {
        return {
          content: [{ type: "text", text: `Error fetching chain info: ${error instanceof Error ? error.message : String(error)}` }],
          isError: true
        };
      }
    }
  • Helper function getBlockNumber that retrieves the current block number for a network using viem public client.
    export async function getBlockNumber(network = 'ethereum'): Promise<bigint> {
      const client = getPublicClient(network);
      return await client.getBlockNumber();
    }
  • Helper function getChainId that retrieves the chain ID for a network using viem public client.
    export async function getChainId(network = 'ethereum'): Promise<number> {
      const client = getPublicClient(network);
      const chainId = await client.getChainId();
      return Number(chainId);
    } 
  • Helper function getRpcUrl that returns the RPC endpoint URL for a given network or chain ID.
    export function getRpcUrl(chainIdentifier: number | string = DEFAULT_CHAIN_ID): string {
      const chainId = typeof chainIdentifier === 'string' 
        ? resolveChainId(chainIdentifier) 
        : chainIdentifier;
        
      return rpcUrlMap[chainId] || DEFAULT_RPC_URL;
    }
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe how it behaves: no information about response format, error handling, rate limits, authentication requirements, or whether it's read-only (though implied by 'Get'). For a tool with zero annotation coverage, this leaves significant behavioral gaps.

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 immediately communicates the core purpose. There's no wasted language or unnecessary elaboration. It's appropriately sized for a simple lookup tool and front-loads the essential information.

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 the tool's simplicity (1 parameter, no output schema, no annotations), the description is minimally adequate. However, it doesn't explain what information is returned (no output schema exists), and with no annotations, it misses behavioral context. For a tool that presumably returns structured network data, the description should at least hint at the return format.

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%, with the single parameter 'network' fully documented in the schema. The description adds no additional parameter information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.

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 verb ('Get') and resource ('information about an EVM network'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'get_supported_networks' (which lists networks) and 'get_block_by_number' (which retrieves blockchain data). However, it doesn't specify what type of information is returned (e.g., chain ID, native currency, RPC URLs), which prevents a perfect score.

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 when network information is needed, but provides no explicit guidance on when to choose this tool over alternatives like 'get_supported_networks' or when network details are required for other operations. The context is clear but lacks specific when-to-use or when-not-to-use instructions.

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/mcpdotdirect/evm-mcp-server'

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