Skip to main content
Glama
dewanshparashar

Arbitrum MCP Server

arb_get_raw_block_metadata

Retrieve raw block metadata for specified block ranges from Arbitrum networks using admin API access.

Instructions

Retrieve raw block metadata for specified block ranges (requires admin API)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rpcUrlNoThe RPC URL of the Arbitrum node (optional if default is set)
chainNameNoChain name (e.g., 'Xai', 'Arbitrum One') - will auto-resolve to RPC URL
fromBlockYesStarting block number
toBlockNoEnding block number (defaults to fromBlock if not provided)

Implementation Reference

  • Core handler function that executes the RPC call to arb_getRawBlockMetadata and processes the response into BlockMetadata array
    async getRawBlockMetadata(
      fromBlock: number,
      toBlock: number
    ): Promise<BlockMetadata[] | { error: string }> {
      try {
        const result = await this.makeRpcCall("arb_getRawBlockMetadata", [
          `0x${fromBlock.toString(16)}`,
          `0x${toBlock.toString(16)}`,
        ]);
    
        if (Array.isArray(result)) {
          return result.map((item: any) => ({
            blockNumber: parseInt(item.blockNumber, 16),
            metadata: item.metadata || item.rawMetadata,
          }));
        }
    
        return {
          error: "Unexpected response format from arb_getRawBlockMetadata",
        };
      } catch (error) {
        return {
          error: `Raw block metadata not supported on this RPC endpoint: ${
            (error as Error).message
          }`,
        };
      }
    }
  • src/index.ts:1119-1148 (registration)
    Tool registration including name, description, and input schema definition in getAvailableTools()
    {
      name: "arb_get_raw_block_metadata",
      description:
        "Retrieve raw block metadata for specified block ranges (requires admin API)",
      inputSchema: {
        type: "object" as const,
        properties: {
          rpcUrl: {
            type: "string",
            description:
              "The RPC URL of the Arbitrum node (optional if default is set)",
          },
          chainName: {
            type: "string",
            description:
              "Chain name (e.g., 'Xai', 'Arbitrum One') - will auto-resolve to RPC URL",
          },
          fromBlock: {
            type: "number",
            description: "Starting block number",
          },
          toBlock: {
            type: "number",
            description:
              "Ending block number (defaults to fromBlock if not provided)",
          },
        },
        required: ["fromBlock"],
      },
    },
  • MCP CallToolRequestSchema handler that instantiates NitroNodeClient and invokes the tool logic
    case "arb_get_raw_block_metadata": {
      const rpcUrl = await this.resolveRpcUrl(
        (args.rpcUrl as string) || (args.chainName as string)
      );
      const nodeClient = new NitroNodeClient(rpcUrl);
      const fromBlock = (args.fromBlock as number) || 0;
      const toBlock = (args.toBlock as number) || fromBlock;
      const metadata = await nodeClient.getRawBlockMetadata(
        fromBlock,
        toBlock
      );
      return {
        content: [
          {
            type: "text",
            text: JSON.stringify(metadata, null, 2),
          },
        ],
      };
    }
  • TypeScript interface defining the output structure for block metadata
    export interface BlockMetadata {
      blockNumber: number;
      metadata: string; // Raw metadata bytes as hex string
    }
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 adds minimal behavioral context: 'requires admin API' hints at authentication needs, but doesn't disclose rate limits, error handling, what 'raw metadata' includes, or if it's read-only/destructive. For a tool with no annotations, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core purpose. It could be slightly more structured by separating prerequisites, but it avoids waste and is appropriately sized.

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 no annotations, no output schema, and a tool that retrieves data with multiple parameters, the description is incomplete. It lacks details on return values, error cases, or how it differs from sibling tools, leaving significant gaps for an AI agent.

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 fully documents all parameters. The description adds no additional meaning beyond the schema (e.g., no clarification on 'raw metadata' or block range behavior). 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.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Retrieve') and resource ('raw block metadata for specified block ranges'), making the purpose understandable. However, it doesn't differentiate this tool from sibling tools like 'arbtrace_block' or 'latest_block' that might also retrieve block-related data, preventing 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 Guidelines2/5

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

The description mentions 'requires admin API' which provides some context about prerequisites, but it offers no guidance on when to use this tool versus alternatives (e.g., 'arbtrace_block' for trace data or 'latest_block' for recent blocks). There's no explicit when/when-not or named alternatives.

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/dewanshparashar/arbitrum-mcp'

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