Skip to main content
Glama
dewanshparashar

Arbitrum MCP Server

sync_status

Check Arbitrum node synchronization status to monitor chain health and verify data availability, with fallback to current block number when sync API is unavailable.

Instructions

Get node synchronization status (may fall back to current block number if sync API unavailable)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rpcUrlNoThe RPC URL of the Arbitrum node (optional if default is set)

Implementation Reference

  • MCP callTool handler case for the 'sync_status' tool. Resolves the RPC URL using chainName or rpcUrl, creates a NitroNodeClient instance, calls getSyncStatus() on it, and returns the result as JSON text content.
    case "sync_status": {
      const rpcUrl = await this.resolveRpcUrl(
        (args.rpcUrl as string) || (args.chainName as string)
      );
      const nodeClient = new NitroNodeClient(rpcUrl);
      const syncStatus = await nodeClient.getSyncStatus();
      return {
        content: [
          {
            type: "text",
            text: JSON.stringify(syncStatus, null, 2),
          },
        ],
      };
    }
  • Input schema and metadata definition for the 'sync_status' tool, registered in getAvailableTools() which is returned by the listTools handler.
      name: "sync_status",
      description:
        "Get node synchronization status (may fall back to current block number if sync API unavailable)",
      inputSchema: {
        type: "object" as const,
        properties: {
          rpcUrl: {
            type: "string",
            description:
              "The RPC URL of the Arbitrum node (optional if default is set)",
          },
        },
        required: [],
      },
    },
  • The core helper function implementing sync status logic. Calls eth_syncing and eth_blockNumber RPC methods, computes progress, with fallback to current block if syncing unavailable.
    async getSyncStatus(): Promise<SyncStatus> {
      try {
        const syncResponse = await this.makeRpcCall("eth_syncing", []);
        const latestBlock = await this.makeRpcCall("eth_blockNumber", []);
    
        if (syncResponse === false) {
          return {
            currentBlock: parseInt(latestBlock, 16),
            highestBlock: parseInt(latestBlock, 16),
            isSyncing: false,
            syncProgress: 100,
          };
        }
    
        const current = parseInt(syncResponse.currentBlock, 16);
        const highest = parseInt(syncResponse.highestBlock, 16);
    
        return {
          currentBlock: current,
          highestBlock: highest,
          isSyncing: true,
          syncProgress: highest > 0 ? (current / highest) * 100 : 0,
        };
      } catch (error) {
        // Try to get at least the current block number as a fallback
        try {
          const latestBlock = await this.makeRpcCall("eth_blockNumber", []);
          const blockNum = parseInt(latestBlock, 16);
          return {
            currentBlock: blockNum,
            highestBlock: blockNum,
            isSyncing: false,
            syncProgress: 100,
            error:
              "Sync status not supported on this RPC endpoint. Showing current block number only.",
          };
        } catch (blockError) {
          return {
            currentBlock: 0,
            highestBlock: 0,
            isSyncing: false,
            syncProgress: 0,
            error:
              "Sync status not supported on this RPC endpoint. This method typically requires access to a node's debug API.",
          };
        }
      }
    }
  • TypeScript interface defining the structure of the SyncStatus response object used by the tool.
    export interface SyncStatus {
      currentBlock: number;
      highestBlock: number;
      isSyncing: boolean;
      syncProgress: number;
      error?: string;
    }
  • src/index.ts:93-102 (registration)
    The listTools request handler that returns all available tools, including 'sync_status', via getAvailableTools() which contains its definition.
    this.server.setRequestHandler(ListToolsRequestSchema, async () => {
      try {
        console.error("Handling list tools request");
        return {
          tools: this.getAvailableTools(),
        };
      } catch (error) {
        console.error("Error in list tools handler:", error);
        throw error;
      }
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 of behavioral disclosure. It effectively reveals key traits: it's a read operation ('Get'), it may have fallback logic, and it depends on API availability. This covers safety and reliability aspects well for a simple tool, though it doesn't detail error handling or response format, which would enhance transparency further.

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 front-loads the core purpose and includes critical behavioral context (the fallback mechanism). There is zero waste or redundancy, making it easy to parse and understand quickly, which is ideal for tool selection by an AI agent.

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?

For a tool with one optional parameter, no annotations, and no output schema, the description is reasonably complete. It covers what the tool does and key behavioral nuances. However, it doesn't explain the return values or potential errors, which would be helpful given the lack of output schema. Overall, it's adequate but could be more comprehensive for full contextual understanding.

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 the parameter 'rpcUrl' clearly documented as optional with a default. The description adds no additional parameter information beyond what the schema provides, such as format examples or usage tips. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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 tool's purpose with a specific verb ('Get') and resource ('node synchronization status'), making it immediately understandable. It distinguishes from siblings by focusing on sync status rather than health, peers, or other node metrics. However, it doesn't explicitly differentiate from tools like 'node_health' or 'comprehensive_chain_status', which might overlap in monitoring contexts.

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 by mentioning a fallback behavior ('may fall back to current block number if sync API unavailable'), which suggests when this tool might be preferred over direct block queries. However, it lacks explicit guidance on when to use it versus alternatives like 'node_health' or 'latest_block', and doesn't specify prerequisites or exclusions, leaving some ambiguity in 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

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