Boost RocketMQ Ops with LLM‑Powered Natural‑Language Queries via GraphQL

Background

In daily operations of TDMQ RocketMQ, engineers often need to query multiple data sources (runtime metrics, broker configuration, topic status, message contents, etc.) to diagnose issues. The traditional workflow requires logging into each system, writing specific query statements, and manually parsing results, which is time‑consuming and error‑prone.

Problem Statement

Operators must be familiar with the query syntax of each data source and switch between different consoles, leading to low efficiency and high cognitive load.

Solution Overview

The team combined a Large Language Model (LLM) with a Chatbox interface, the MCP protocol, and GraphQL to create a one‑stop natural‑language query platform. Users type a plain‑language request, the LLM translates it into a GraphQL query, MCP sends the query to the appropriate backend services, and the LLM formats the JSON response back into human‑readable text.

Architecture Details

In this pipeline:

LLM – core natural‑language processor.

Chatbox – user‑facing input component.

MCP – protocol that wraps GraphQL calls (acts as a GraphQL client).

GraphQL – unified query language that can reach any data source (REST, binary protocols, etc.).

The LLM receives the user’s sentence, generates a GraphQL query, MCP forwards it, the backend returns JSON, and the LLM converts the JSON into a concise answer.

Example Scenario: Querying Broker Information

To fetch the address, configuration, topic list, queue offsets, and a specific message from Broker_One, the following GraphQL query is generated:

query {
  # Query Broker node Broker_One
  brokers(name: "Broker_One") {
    # Endpoint address
    addr
    # Configuration item messageIndexEnable
    config(name: "messageIndexEnable") {
      name
      value
    }
    # Topic information: Topic_A
    topics(name: "Topic_A") {
      # Queue 0 of the topic
      queues(id: 0) {
        # Queue offsets
        minOffset
        maxOffset
        # 100th message in the queue
        messages(offset: 100) {
          id
          payload
        }
      }
    }
  }
}

This single query aggregates five sub‑queries: broker address, configuration, topic metadata, queue offsets, and a specific message payload.

Why GraphQL?

GraphQL lets the client specify exactly which fields are needed, enabling nested queries that map naturally to the hierarchical data model of RocketMQ (broker → topic → queue → message). It also provides a self‑describing schema, which the LLM can introspect to understand available data structures.

Simplified Development : No need to write separate MCP servers for each source; GraphQL acts as a universal data‑access layer.

Simplified Queries : Operators only learn GraphQL syntax, not the specifics of each backend.

Reduced Calls : One GraphQL request can retrieve data from multiple sources, saving token usage.

Lower Context Overhead : The LLM focuses on the problem rather than low‑level API details.

Flexible Schema Evolution : Adding new data structures only requires updating the GraphQL schema; the LLM automatically adapts.

Implementation Highlights

The system also uses the introspect‑schema GraphQL operation once at the start of a conversation to fetch the schema, enabling the LLM to understand field names and types. In production, a proper MCP‑compatible client (e.g., Claude Desktop) should be used to avoid repeated schema calls.

Conclusion and Future Work

The LLM + Chatbox + MCP + GraphQL stack allows operators to diagnose RocketMQ issues with natural language, removing the need for deep system knowledge and manual query crafting. Future plans include feeding expert troubleshooting knowledge into the LLM as a knowledge base, moving toward a fully automated, one‑stop problem‑resolution system.