GDS Agent for Graph Algorithmic Reasoning

TL;DR

The GDS agent adds a graph-analytic toolset to LLM-based reasoning by coupling a Model Context Protocol server with a library of graph algorithms to reason over private knowledge graphs. It leverages Cypher projections to create in-memory subgraphs and uses tool-then-answer workflows (e.g., Yen's shortest paths) to ground LLM responses in actual graph analytics. Benchmarking on London Underground and GoT datasets shows the approach can solve a broad class of graph tasks, but performance varies with output size and data availability. The work highlights practical challenges such as token limits, tool invocation fidelity, and data requirements, and outlines future directions to improve reliability and scalability of graph-aware AI assistants.

Abstract

Large language models (LLMs) have shown remarkable multimodal information processing and reasoning ability. When equipped with tools through function calling and enhanced with retrieval-augmented techniques, compound LLM-based systems can access closed data sources and answer questions about them. However, they still struggle to process and reason over large-scale graph-structure data. We introduce the GDS (Graph Data Science) agent in this technical report. The GDS agent introduces a comprehensive set of graph algorithms as tools, together with preprocessing (retrieval) and postprocessing of algorithm results, in a model context protocol (MCP) server. The server can be used with any modern LLM out-of-the-box. GDS agent allows users to ask any question that implicitly and intrinsically requires graph algorithmic reasoning about their data, and quickly obtain accurate and grounded answers. We introduce new benchmarks that evaluate intermediate tool calls as well as final responses. The results indicate that GDS agent is able to solve a wide spectrum of graph tasks. We also provide detailed case studies for more open-ended tasks and study scenarios where the agent struggles. Finally, we discuss the remaining challenges and the future roadmap.

Figures (12)

• Figure 1: A snapshot of an example KG stored in Neo4j, representing a version of the London underground map. The nodes represent stations, each having textual and numerical properties such as name and total_lines. The edges represent station links, each having properties such as line, distance and time.
• Figure 2: An example Cypher projection on the database in Figure \ref{['fig:ln-map']}. The Cypher query first retrieves all nodes and directed edges. WITH the materialised graph from the DB, an in-memory graph of the name graph_name is created. Labels on source nodes and target nodes are kept. Types of all relationship are kept. All source nodes have two properties: zone and total_lines, using values from the DB with appropriate types. All target nodes have the same properties. All relationships have two properties: distance and time. Note that more complex Cypher queries with filtering and aggregations can be used as well.
• Figure 3: Architecture of GDS Agent by example. A user asks a questions about their database given by Figure \ref{['fig:ln-map']}. GDS Agent invokes several tools to obtain a final answer. Round orange boxes represent tool calls. Square orange boxes represent raw returned data from tool calls. The sequence of actions is given by the numbers. The LLM generates the final answer based on the user question and all tool call results as context.
• Figure 4: Some examples from the graph-agent-bench-ln-v1 benchmark. The first example instructs the agent to execute a specific parameterised algorithm. The latter two examples are questions that require the agent to understand the intent and pick appropriate tools and parameters.
• Figure 5: Plots of the distributions of the number of turns and tokens used for answer each question.