GDS Agent for Graph Algorithmic Reasoning

TL;DR

The paper introduces the GDS agent, a system that enhances large language models with graph algorithms and retrieval techniques, enabling effective reasoning over large-scale graph data and improving performance on graph-related tasks.

Contribution

It presents the GDS agent, integrating graph algorithms as tools within LLMs, along with a model protocol server, to facilitate graph reasoning and new benchmark evaluations.

Findings

GDS agent effectively solves diverse graph tasks.

Introduces benchmarks for intermediate tool call evaluation.

Provides case studies and discusses future challenges.

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.

Tables

Table 1. Table 1 : Evaluation metrics summary. The first four metrics evaluates intermediate tool calls. The last metric evaluates the final output of the agent. Tool Precision = unique correct calls / total actual calls. Tool Recall = unique correct calls / expected calls. Parameter Match = Correct parameter values / all parameters. Answer Match = matched items / total expected items.

Metric	Mean $\pm$ Std	Median	Min	Max
Tool Precision	0.769 $\pm$ 0.326	1.00	0.0	1.0
Tool Recall	0.849 $\pm$ 0.268	1.00	0.0	1.0
Tool F1	0.754 $\pm$ 0.274	0.80	0.0	1.0
Parameter Match	0.889 $\pm$ 0.247	1.0	0.0	0.0
Answer Match	0.657 $\pm$ 0.450	1.0	0.0	1.0

Full text

https://github.com/neo4j-contrib/gds-agent

1 Introduction

Recent progress in transformer-based large language models (LLMs) has shown remarkable multimodal processing and reasoning power(anthropic2025claude4; openai2025gpt41; 2025gemini; grattafiori2024llama; guo2025deepseek; yang2025qwen3; grattafiori2024llama). However, a fundamental limitation of these models is that they cannot directly access and interact with private data. Retrieval-augmented methods(lewis2020retrieval) address the problem by retrieving relevant content from a private database for a user question and then feeding it into an LLM for reasoning. Functional calling(functiona-calling; structured-output) capabilities allow an LLM to generate structured outputs which are used to invoke external tool calling. Such a compound system(compound-ai-blog) of LLMs and tools (other software libraries and APIs) becomes an agent. An agent(yao2023react) is triggered by a user question (prompt), driven by the LLMs which call tools to interact with external systems and databases. There are a growing number of agents for a variety of use cases, including being a coding assistant, domain-expert researcher, and medical assistant(plaat2025agentic).

Among many modalities of data, graphs naturally represent a wide range of real-world data. A social network can be modeled as a graph with users being the nodes and interactions between the users forming the edge set. An underground transport network has stations as nodes and connections as edges. Records of financial transactions can be modeled as a graph with accounts as the nodes and transactions as the edges. Many real-world graphs are heterogeneous, containing different node and edge types, and attributed, having diverse node and edge properties of different types. Such graphs are commonly referred to as Knowledge Graphs (KGs).

Current transformer-based LLMs or pure transformers have limited graph reasoning ability. Existing theoretical and empirical studies adopt the setup of specialized graph transformers that tokenize individual nodes and edges(sanford2024understanding; kim2022pure) or textualize the graph and prompt the LLM(he2024g; fatemi2023talk; clemedtson2025graphraft). The first setup limits out-of-the-box adoption with existing LLMs. The second is dependent on adhoc textualization scheme, and is bounded by the context window and inherits issues that arise from long context(liu2023lost). Existing benchmarks fall into two categories. The first being knowledge-base question answering(yang2018hotpotqa; wu24stark) that represent few-hop retrieval on KGs. For example, the question “Who is a friend of Alice that knows Bob?” might have answer “Charlie” in a social network database. The second category measures how well LLMs are able to simulate various graph algorithms. The questions are commonly given by textualized graphs, such as “My graph is represented by an edge list: [(0,1),(1,2),(2,3)]. How many triangles are there?”. Existing LLMs can only simulate basic algorithms on relatively small-scale simple graphs(markeeva2024clrs; taylor2024large; openai2025gpt41; graphwalks).

In this technical report, we introduce GDS (Graph Data Science) agent. GDS agent is a LLM-based agent equipped with a comprehensive set of graph algorithms as tools. GDS Agent is able to answer a wide range of questions that implicitly and intrinsically require graph algorithmic reasoning on real-world knowledge graphs. For example, it is able to answer “What are a few quickest ways to go from Station A to Station B” by invoking Yen’s algorithm with appropriate parameters such as start node, end node and the value of $k$, against a private network. As another example, a data scientist might want to understand what are the important accounts in their social network platform. The agent is able to analyze the data by utilizing community and centrality algorithms and provide a report to the data scientist.

GDS agent addresses a wide range of common tasks on large-scale KGs that existing LLM-based frameworks and agentic systems are unable to solve. Users are able to collaborate with the agent to analyze their graphs. The agent greatly amplifies the usefulness of LLMs for large-scale KGs and removes the barrier of leveraging graph analytics libraries.

2 Preliminaries

Many real-world KGs are stored in native graph databases such as Neo4j(neo4j) which offers efficient disk storage and access. An example such graph is shown in Figure 1. Users are able to query their data with Cypher(cypher). Other similar graph query languages include openCypher(opencypher). They evolved into the recently formed GQL(gql) standard. The key feature of Cypher, and all graph query languages, is graph pattern matching. As a basic example, MATCH (n:A)-[:R1]->(m:B) RETURN DISTINCT m finds all distinct nodes of type B that are some target nodes of relationships with type R1, from any source node of type A. Query engines built on top of graph databases are able to optimize query plans, ensuring efficient execution. The expressiveness of the query language(gheerbrant2024gql) ensures a wide range of end-user questions can be formulated as Cypher queries.

However, there still exist a wide range of real-world questions that cannot be answered with Cypher alone. For example, finding various shortest paths, computing centrality scores and detecting communities of nodes under some optimization criteria. Such tasks correspond to running graph algorithms on KGs. The GDS(gds) library offers a comprehensive set of such algorithms. The available algorithms range from centrality, path-finding, community to node similarity algorithms. The implementation are highly parallelizable and memory-efficient.

In order to execute a GDS algorithm, one has to first perform a Cypher projection which constructs a in-memory (sub)graph from the Neo4j database. In-memory projection provides subgraph retrieval with property and type filtering, as well as on-the-fly transformations. String properties present in the database are not projected, since none of the classical graph algorithms leverage such property. Multiple algorithms can be execute on a projected graph and the projected graph can also be mutated, for example with additional properties. The actual algorithms can run efficiently on the projected graph, independent of the database. An example Cypher projection is given in  Figure 2.

3 Architecture

We present the architecture of GDS Agent with a concrete example. The core part of the agent is a Model Context Protocol (MCP) server(mcp) containing tools including GDS algorithms. Any LLM that supports functional calling using structured output may be used as the MCP client within the agent. The server connects the database with the provided crediential such as NEO4J_URL. The full list of tools is given in Appendix A.

For example, a user can ask “I want to know a few quickest ways that I can go from Paddington to London Bridge” against a database containing a version of the London underground map from  Figure 1. Intuitively, the LLM understands that the question requires finding some shortest paths between the source and the target station with the constraints that they need to be “quickest” and the requirement of finding “a few” of them.

\raisebox{-0.9pt}{1}⃝The agent decides to invoke the get_node_properties_keys tool which fetches all the available node properties in the database. The call returned a list of properties including name (string), id (string), total_lines (int) and zone (float).

\raisebox{-0.9pt}{2}⃝The agent then decides to execute the get_relationship_properties_keys tool, which returns a list of properties including line (string), distance (float), time (float).

\raisebox{-0.9pt}{3}⃝Each tool in the server has a tool specification using the JSON format in the MCP standard. A tool specification contains a description field, as well as a dictionary of parameters, their types and their descriptions. An example tool specification for Yen’s algorithm(yens) is given in Appendix B. The LLM inspects the specifications and determines yens_shortest_paths as the appropriate tool to call. The LLM also creates a dictionary of parameter key-value pairs that are passed to the tool. These are usually algorithm related, for example the choice of $k$ for Yens. The tool first performs a Cypher projection to create a projected graph. Note that in this case, any textual properties on nodes and edges are dropped.

\raisebox{-0.9pt}{4}⃝The yens_shortest_paths tool then executes the GDS Yen’s algorithm on the projected graph. As the projected graph does not contain any string properties such as names, the source and target node need to be mapped to the internal ids representing ”Paddington” and ”Lodon Bridge”. For this, the LLM must first select the appropriate identifying property from those returned by the get_node_properties_keys call. The LLM settles on using ”name” instead of other alternatives like ”rail” or ”display_name”. This is passed to the tool with the nodeIdentifierProperty: "name" parameter. The tool then internally invokes gds.shortestPath.yens algorithm with the source and target node ids, with parameters relationshipWeightProperty: "time" and k: 3. k specifies the top k shortest paths to be returned. The LLM in this case interprets “a few” as finding 3 such paths. The algorithm returns a dataframe of 4 columns: index, costs, nodeIds, path. Each row represent a path, with the corresponding cost of each edge, the list of node ids traversed in the paths, and a full description of the path data, including names. The result dataframe is serialized to a textual description and fed into the LLM.

The LLM generates the final answer based on the user question and all textualised tool responses as context. It provides a summary of the 3 quickest routes, describing the time and detailed path for each of them. A user can obtain this answer with no graph data science expertise. A user can evaluate and explain the final answer by inspecting their database, as well as examining tool invocations, along with their parameters and the raw returned data.

4 Benchmarks

We introduce two new benchmarks consisting of representative datasets and questions. graph-agent-bench-ln-v1 is based on a version of the London underground map(tube-map) shown in Figure 1. graph-agent-bench-got-v1 is based on a version of the Game of Thrones datasetgot-dataset containing Kings and Knights belonging to different houses and involved in various battles.

For each dataset, we provide a set of questions of varying levels of difficulties that require specific tool usages to answer. For each question, we provide the expected tool calls, the expected tool parameters and expected answers. All questions are written manually by the authors. The algorithm parameters have been specifically selected to minimize the chance of varying results, but they might still happen because of parallelism occasionally for a few of questions without a unique answer e.g., a node might actually be classified in a different community between runs.

Our full benchmark is at https://github.com/brs96/gds-agent-benchmarks. Some examples from graph-agent-bench-ln-v1 are shown in Figure 4. All experiments were conducted using version 0.5.1 of the GDS agent MCP server. We use sonnet-4-20250514 as the LLM of choice unless otherwise specified. All results for graph-agent-bench-got-v1 are included in Appendix C.

4.1 Discussion

We present some basic statistics in Figure 5. For the most part, the model responds well to the question set. This is shown in Figure 5(a) where we can see that the mean number of turns is generally low. This corresponds to the client calling a few basic pre-processing tools such as get_node_properties_keys, the appropriate algorithm tool, and doing some post-processing work for each question. We attempt to explain the few edge-cases with a higher number of turns, by looking at how model behaved for the following question: I would like to use the Dijkstra single-source shortest path to find all paths from Arsenal, using distance as the weight. Provide the paths with costs as answers. The example format is: ["Holloway Road", "X"]: [0.0, 42.0], ["Holloway Road", "B", "C"]: [0.0, 9.5, 9.6].

The agent initially correctly calls dijkstra single-source algorithm with the right arguments. Because the output ends up being too large, processing it would surpass number of allowed tokens and it stops doing so. The model then switches to a different approach and calls source-target shortest path queries between Dijkstra and arbitrarily selected target nodes and then terminates without actually being able to generate an answer. Dealing with large output appears to be a cause of problems in general. For example, a question regarding Bellman-Ford -another path-finding algorithm- similarly surpassed the number of tokens, although in this case the model did not try other tools. The number of turns used is 4. Figure 5(b) complements Figure 5(a) by showing the distribution of number of tokens used for each question.

Table 1 shows that for the majority of questions, the LLM calls the correct algorithm tools with the correct parameters by presenting statistics such recall and precision which are both very high on average. We briefly mention two factors that explain the lower scores in some cases. The first is a planning tool ”todoWrite” that the model might use to broadcast the course of actions it will follow. Use of this tool is not expected and the precision drops when called. The second is that occasionally the model can guess the appropriate nodeIdentifierProperty without calling get_node_properties_keys beforehand. This might partly be explained by the dataset as the identifying property ”name” is a fairly standard one that appears in many use-cases, and the model might decide to try it first especially if the question contains keywords such as "named". When this happens, it can lower the recall score.

For most of the questions, the agent finds the correct answer. We present a few cases of ambiguity that occur by the LLM’s processing of results. We start by considering the third question in Figure 4 that tests the node similarity tool. Its expected results are symmetric, e.g., the similarity pair Chesham-Amersham appears twice in the expected output. This is on par with the underlying GDS library implementation which also returns symmetric results. Whilst benchmarking, we have seen runs where all eight pairs are returned, but also runs where only the unique four pairs are returned. In the second case the model’s behavior poses an interesting question. We specifically asked for eight answers yet only received four back. As the agent decided to deduplicate the results, should it had attempted to rerun the algorithm with a higher ”topN” value to guarantee that eight distinct pairs can be returned?

Another question with often ambiguous results is the following: Execute BFS on my database with source station Aldgate and max depth 4. The result data should be paths, for example: ["A", "B", "C"], ["D, "A", "F"]. Figure 4.1 shows the output on two different executions.

⬇

Answer 1:

The BFS result shows the traversal order and visited stations. Let me format this as paths by extracting the station names in the order they were visited. The BFS from Aldgate with max depth 4 found 35 stations total, visiting them in breadth-first order:

BFS Paths from Aldgate (max depth 4):

‘‘‘

["Aldgate", "Liverpool Street", "Tower Hill", "Aldgate East"]

["Aldgate", "Bank", "Moorgate", "Bethnal Green", "Monument", "Whitechapel"]

["Aldgate", "London Bridge", "Shadwell", "St. Paul’s", "Waterloo", "Old Street", "Barbican", "Mile End", "Cannon Street", "Stepney Green", "Shoreditch"]

["Aldgate", "Borough", "Bermondsey", "Southwark", "Limehouse", "Wapping", "Tower Gateway"]

["Aldgate", "Chancery Lane", "Embankment", "Kennington", "Lambeth North", "Westminster", "Angel", "Farringdon", "Bow Road", "Stratford", "Mansion House"]

‘‘‘

The search found 35 stations within 4 hops from Aldgate, exploring the network in breadth-first order across the London Underground system.,

Answer 2:

The BFS traversal from Aldgate with max depth 4 found 35 nodes. However, the current output format shows node objects rather than paths. Let me extract the station names to create the path format you requested:

BFS Traversal from Aldgate (max depth 4):

The traversal visited these stations in order:

• Depth 0: Aldgate

• Depth 1: Liverpool Street, Tower Hill, Aldgate East

• Depth 2: Bank, Moorgate, Bethnal Green, Monument, Whitechapel, London Bridge, Shadwell

• Depth 3: St. Paul’s, Waterloo, Old Street, Barbican, Mile End, Cannon Street, Stepney Green, Shoreditch, Borough, Bermondsey, Southwark, Limehouse, Wapping, Tower Gateway

• Depth 4: Chancery Lane, Embankment, Kennington, Lambeth North, Westminster, Angel, Farringdon, Bow Road, Stratford, Mansion House

Total stations reached: 35 within 4 steps from Aldgate

The algorithm explores all reachable stations within the specified maximum depth, showing the breadth-first exploration pattern from the source station.

Figure 6: Varying results on running BFS from the graph-agent-bench-ln-v1 benchmark.

In the second answer the model completely ignores one of the instructions of the prompt which explicitly specifies the output format. Furthermore, in both cases some nonarbitrary post-procssing is applied on the returned results. The BFS implementation in GDS Library returns a BFS ordering from which is neither possible to deduce the depth of a given node nor to find out how nodes are connected with each other.

We also experiment with equipping different LLMs with the same set of tools in order to understand whether different frontier LLMs are able to understand the questions and use the right tools equally well. For all OpenAI models, we use reasoning effort minimal and verbosity low. All other system and model settings, such as temperature and max token limits, are default values.

Figure 7 shows that different agents (with different LLMs) exhibit varying ability to use the tools. There are questions that all agents fail to solve. There is also no strong correlation between the metrics that measure tool invocations and the final results. For example, the agent with GPT-4o has the highest precision for calling the right tools. However, it at the same time has a low tool recall and answer accuracy. GPT-5 shows significantly higher accuracy (85.4%) for final answers. It is able to achieve this by almost always calling the necessary tools (93.3% recall), even though it sometimes makes additional unnecessary calls (74.6% precision).

5 Case Studies

5.1 Open-ended graph tasks

We examine how the agent behaves when faced with inherently open-ended ambiguous tasks. In Figure 5.1, we ask the agent to find out what are the most important stations in the network. The model starts with invoking several centrality algorithms, including pagerank, betweenness, degree and closeness. It then summarizes the algorithm results. This case study shows that the agent is able to make progress for a simple open-ended task. Note that the LLM attemtps to provide “concise interpretations” for the algorithms. For example, it refers to stations with high betweenness centrality as “strategic bottlenecks”. Note that for this dataset, which significantly overlaps with known public data, the LLM also injects it’s internal knowledge in the summary, for example referring to Embankment as “River crossing point”. Such information is not retrieved from the database or available in the algorithm results.

⬇

You are a graph data science assistant. I have a transport network in my database. I would like to find out what are the most important stations in my network, and why. Provide me with a brief and accurate report with explanations.

• I’ll analyze your transport network to identify the most important stations and explain why they’re critical to the system.

• Update Todos

[] Calculate multiple centrality measures for all stations

[] Identify top stations by different importance metrics

[] Analyze why these stations are important

[] Generate comprehensive importance report

• Update Todos

[] Calculate multiple centrality measures for all stations

[] Identify top stations by different importance metrics

[] Analyze why these stations are important

[] Generate comprehensive importance report

• neo4j-gds - pagerank (MCP)(nodeIdentifierProperty: "name")

nodeId score nodeName

0 0 0.346293 Acton Town

1 58 0.311866 Ealing Common

... +300 lines (ctrl+r to expand)

• neo4j-gds - betweenness_centrality (MCP)(nodeIdentifierProperty: "name")

nodeId score nodeName

0 0 8.000000 Acton Town

1 58 9.000000 Ealing Common

... +300 lines (ctrl+r to expand)

• neo4j-gds - degree_centrality (MCP)(nodeIdentifierProperty: "name")

nodeId score nodeName

0 0 3.0 Acton Town

1 58 2.0 Ealing Common

... +300 lines (ctrl+r to expand)

• neo4j-gds - closeness_centrality (MCP)(nodeIdentifierProperty: "name")

nodeId score nodeName

0 0 0.750000 Acton Town

1 58 0.750000 Ealing Common

... +300 lines (ctrl+r to expand)

• Update Todos

[#] Calculate multiple centrality measures for all stations

[] Identify top stations by different importance metrics

[] Analyze why these stations are important

[] Generate comprehensive importance report

• Update Todos

[#] Calculate multiple centrality measures for all stations

[#] Identify top stations by different importance metrics

[] Analyze why these stations are important

[] Generate comprehensive importance report

• Update Todos

[#] Calculate multiple centrality measures for all stations

[#] Identify top stations by different importance metrics

[#] Analyze why these stations are important

[#] Generate comprehensive importance report

• Transport Network Station Importance Analysis

Based on comprehensive centrality analysis of your 302-station transport network, here are the most important stations and the reasons for their significance:

Top Critical Stations by Importance Type

1. Network Flow Hubs (PageRank)

• Westminster (1.058) - Highest overall network importance

• Russell Square (0.917) - Major flow concentrator

• Waterloo (0.882) - Critical interchange point

• West Ham (0.830) - Eastern network hub

• Turnham Green (0.815) - Western connector

2. Strategic Bottlenecks (Betweenness Centrality)

• Paddington (12.0) - Most critical pathway control

• Bond Street (11.0) - Central connection point

• Green Park (11.0) - Key transfer hub

• King’s Cross St. Pancras (10.0) - Major interchange

• Oxford Circus (9.0) - Central London nexus

3. Connectivity Centers (Degree Centrality)

• Baker Street (10 connections) - Most connected station

• Bank (6 connections) - Financial district hub

• Barbican (6 connections) - Multi-line intersection

• Embankment (6 connections) - River crossing point

• Earl’s Court (6 connections) - West London interchange

Why These Stations Are Critical

Strategic Control Points

• Paddington controls the most shortest paths (betweenness 12.0), making it essential for east-west connectivity

• Bond Street and Green Park serve as central London bridges between network regions

High-Traffic Interchanges

• Baker Street has 10 direct connections, making it the most physically connected station

• Westminster dominates network-wide flow patterns (PageRank 1.058)

• King’s Cross St. Pancras handles critical north-south traffic flows

Network Resilience

• Bank, Barbican, and Embankment provide redundant connectivity with 6 connections each

• These stations ensure network robustness against disruptions

Regional Gateways

• West Ham serves as the primary eastern hub (PageRank 0.830)

• Turnham Green connects western branches (PageRank 0.815)

• Russell Square centralizes northern flows (PageRank 0.917)

Impact Assessment

Disruption to these top-tier stations would have cascading effects:

• High betweenness stations would force longer alternative routes

• High degree stations would fragment network connectivity

• High PageRank stations would reduce overall network efficiency

The analysis reveals a hub-and-spoke architecture with these stations forming the critical backbone of your transport system’s connectivity and passenger flow management.

Figure 8: Case study of understanding station importance. The agent invokes several centrality algorithms and summarizes the results. The agent attempts to provide concise and intuitive interpretations of the algorithm results, and injects internal knowledge for data that significantly overlap with publicly available facts.

In Figure 5.1, we ask the agent to analyze the zone information available on the nodes and provide a short report of how the zones are assigned. The agent proceeds to execute centrality (degree) and community (weakly connected components) algorithms. It then executes pagerank and betweenness centrality on selected stations, seemingly combining with its internal knowledge. The agent has generally taken the right approach to analyze centrality and community structure. The actual zones are assigned as roughly concentric rings in a way that is not solely based on network analysis(london-zone). This use case illustrates the scenario where the agent makes a reasonable contribution for task that requires both network analysis and further interactive collaboration with the user that provides additional guidance and expertise.

⬇

You are an graph data science assistant that helps analyse the graph in my database. I have a transport network with stations containing zone information. I would like to understand how the zones are assigned to the stations. Provide an accurate explanation.

• I’ll help you analyze the zone assignments for stations in your transport network. Let me start by exploring your graph database to understand the structure and then provide insights about how

zones are assigned to stations.

• Update Todos

[] Examine the graph structure to understand nodes and relationships

[] Identify station nodes and their zone properties

[] Analyze zone distribution patterns across stations

[] Provide insights on zone assignment logic

• Update Todos

[] Examine the graph structure to understand nodes and relationships

[] Identify station nodes and their zone properties

[] Analyze zone distribution patterns across stations

[] Provide insights on zone assignment logic

302

[

"zone",

"latitude",

... +7 lines (ctrl+r to expand)

[

"distance",

"line",

... +2 lines (ctrl+r to expand)

• Update Todos

[#] Examine the graph structure to understand nodes and relationships

[] Identify station nodes and their zone properties

[] Analyze zone distribution patterns across stations

[] Provide insights on zone assignment logic

• Perfect! I can see your transport network has 302 stations, each with zone information along with other properties like coordinates, names, and rail connectivity data. Let me analyze the zone

distribution patterns.

• neo4j-gds - degree_centrality (MCP)(nodeIdentifierProperty: "name", nodes: [])

Empty DataFrame

Columns: [nodeId, score, nodeName]

Index: []

• Let me try a different approach to examine the stations and their zones:

• neo4j-gds - weakly_connected_components (MCP)(nodeIdentifierProperty: "name")

nodeId componentId nodeName

0 0 0 Acton Town

1 58 0 Ealing Common

... +300 lines (ctrl+r to expand)

• Update Todos

[#] Examine the graph structure to understand nodes and relationships

[#] Identify station nodes and their zone properties

[] Analyze zone distribution patterns across stations

[] Provide insights on zone assignment logic

• Now let me analyze how zones relate to the geographic distribution and connectivity of stations by looking at centrality measures:

• neo4j-gds - pagerank (MCP)(nodeIdentifierProperty: "name", nodes: ["Bank","Oxford Circus","King’s Cross St. Pancras","Liverpool Street","London Bridge","Waterloo","Victoria","Paddington","Bond

Street","Green Park"])

nodeId score nodeName

5 136 0.351875 Liverpool Street

16 126 0.763753 King’s Cross St. Pancras

... +10 lines (ctrl+r to expand)

• neo4j-gds - betweenness_centrality (MCP)(nodeIdentifierProperty: "name", nodes: ["Bank","Oxford Circus","King’s Cross St. Pancras","Liverpool Street","London

Bridge","Waterloo","Victoria","Paddington","Bond Street","Green Park"])

nodeId score nodeName

5 136 6.000000 Liverpool Street

16 126 10.000000 King’s Cross St. Pancras

... +10 lines (ctrl+r to expand)

• Update Todos

[#] Examine the graph structure to understand nodes and relationships

[#] Identify station nodes and their zone properties

[#] Analyze zone distribution patterns across stations

[] Provide insights on zone assignment logic

• Update Todos

[#] Examine the graph structure to understand nodes and relationships

[#] Identify station nodes and their zone properties

[#] Analyze zone distribution patterns across stations

[#] Provide insights on zone assignment logic

• Based on my analysis of your transport network graph database, here’s how zones are assigned to stations:

Zone Assignment Analysis

Your transport network contains 302 stations with zone information stored as a node property. The zone assignments follow a typical transport fare system structure:

Key Findings:

1. Network Structure: All stations are connected in a single component, forming a comprehensive transport network with geographic coordinates (latitude/longitude) for each station.

2. Central Hub Pattern: High-centrality stations like Waterloo (PageRank: 0.88), King’s Cross St. Pancras (PageRank: 0.76), and Paddington (PageRank: 0.43) are major interchange hubs that likely occupy central zones.

3. Geographic Distribution: The zone system appears to follow a concentric ring model radiating outward from central London:

• Central stations (Bank, Oxford Circus, Bond Street) form the core

• Major terminals (Waterloo, King’s Cross, Paddington, Victoria) serve as zone boundaries

• Peripheral stations extend to outer zones

4. Connectivity-Based Logic: Stations with higher betweenness centrality (Paddington: 12.0, Bond Street: 11.0, Green Park: 11.0) act as critical transfer points, suggesting zone boundaries are designed around transport interchange efficiency.

Zone Assignment Logic:

The zones appear to be assigned based on:

• Distance from city center (geographic proximity to central London)

• Network importance (interchange stations often define zone boundaries)

• Line connectivity (stations serving multiple lines typically in lower-numbered zones)

• Travel time considerations (fare zones correlate with journey duration)

This creates a fare structure where passengers pay based on how far they travel from the city center, with zones designed to balance revenue generation with network accessibility.

Figure 9: Case study of how analyzing how zones are assigned to the nodes. The agent makes a reasonable effort to perform network analysis. However, the task is inherently challenging and requires the user to collaborate with the agent to provide additional guidance and expertise.

5.2 Failure Modes

We examine scenarios when the agent struggle to answer the questions. In Figure 5.2, we ask the agent to analyze the capacity of network, by calculating how many people can transit between two stations. The challenge is twofold. The underlying database does not contain any data regarding the capacity of the links or the network. We also exclude any network capacity algorithm such as max flow algorithms, which means there is no simple way for the agent to reliably calculate the answer. The expected outcome is for the agent to acknowledge the failure and point out the missing data and tool.

As shown by Figure 5.2, the agent attemtps to find shortest paths between the stations using Dijkstra’s and Yen’s algorithms. It incorrectly reasons that the maximum flow is the aggregate of the two equally optimal paths that were found. This failure suggest that frontier LLMs still struggle to understand graph algorithmic questions and fail to acknowledge missing data and tools and are prone to pretend to reason.

⬇

You are a helpful graph data science assistant. I have a transport network in my database. I am analysing the capacity of the transport network. Specifically, I want to know what is the

maximum capacity between Paddington and London Bridge. For example, this could be knowing how many people can be transported between these two stations in a day.

• I’ll help you analyze the maximum capacity between Paddington and London Bridge in your transport network. Let me start by exploring your Neo4j database to understand the structure and then

find the optimal paths.

• Update Todos

[] Explore database structure and available node/relationship properties

[] Find Paddington and London Bridge stations in the network

[] Analyze capacity-related properties in relationships

[] Calculate maximum flow/capacity between the two stations

• Update Todos

[] Explore database structure and available node/relationship properties

[] Find Paddington and London Bridge stations in the network

[] Analyze capacity-related properties in relationships

[] Calculate maximum flow/capacity between the two stations

302

[

"zone",

"latitude",

... +7 lines (ctrl+r to expand)

[

"distance",

"line",

... +2 lines (ctrl+r to expand)

• Update Todos

[#] Explore database structure and available node/relationship properties

[] Find Paddington and London Bridge stations in the network

[] Analyze capacity-related properties in relationships

[] Calculate maximum flow/capacity between the two stations

• Your transport network has 302 stations with properties like name, location coordinates, and zone information. The relationships have distance, line, and time properties. Let me find the

Paddington and London Bridge stations and explore the shortest paths between them.

• neo4j-gds - find_shortest_path (MCP)(start_node: "Paddington", end_node: "London Bridge", nodeIdentifierProperty: "name")

{

"totalCost": 8.0,

"nodeIds": [

... +46 lines (ctrl+r to expand)

• Update Todos

[#] Explore database structure and available node/relationship properties

[#] Find Paddington and London Bridge stations in the network

[] Analyze capacity-related properties in relationships

[] Calculate maximum flow/capacity between the two stations

• Great! I found a path from Paddington to London Bridge through 8 stations with a total cost of 8.0. Now let me find alternative paths to analyze the maximum capacity. Since your network

doesn’t have explicit capacity properties, I’ll use Yen’s algorithm to find multiple shortest paths.

• neo4j-gds - yens_shortest_paths (MCP)(sourceNode: "Paddington", targetNode: "London Bridge", nodeIdentifierProperty: "name", k: 5)

{

"found": true,

"sourceNodeId": 167,

... +259 lines (ctrl+r to expand)

• Update Todos

[#] Explore database structure and available node/relationship properties

[#] Find Paddington and London Bridge stations in the network

[#] Analyze capacity-related properties in relationships

[#] Calculate maximum flow/capacity between the two stations

• Based on my analysis of your London transport network, I found two distinct optimal paths between Paddington and London Bridge, both with a cost of 8 stops:

Primary Route:

Paddington -> Edgware Road -> Baker Street -> Bond Street -> Green Park -> Westminster -> Waterloo -> Southwark -> London Bridge

Alternative Route:

Paddington -> Edgware Road -> Baker Street -> Bond Street -> Green Park -> Westminster -> Waterloo -> Bank -> London Bridge

Capacity Analysis:

Maximum theoretical capacity: Since there are 2 equally optimal paths with 8 stations each, the maximum flow would be 2 parallel routes operating simultaneously.

Key bottlenecks to consider:

• Paddington: 4 total lines (good capacity)

• Baker Street: 5 total lines (excellent interchange capacity)

• Green Park: 3 total lines (moderate capacity)

• Waterloo: 4 total lines (good capacity)

• London Bridge: 2 total lines (potential bottleneck)

London Bridge appears to be the limiting factor with only 2 total lines, making it the capacity constraint for the entire route.

For real-world capacity calculations, you’d need to multiply by actual train frequencies, passenger capacity per train, and operating hours per day. The network structure suggests the maximum flow is limited by London Bridge’s 2-line capacity rather than the availability of alternative paths.

Figure 10: Case study of asking the agent to understand the capacity of the network by computing how many people can travel between two stations. The database does not have any capacity information and the agent are not equipped with network capacity algorithms. The agent fails to solve the task and attempts to reason, incorrectly, using available tools.

6 Conclusion

In this technical report, we introduced the GDS agent. It consists of an MCP server with graph algorithms as tools and an LLM as the MCP client. Users can collaborate with GDS agent to solve a wide variety of common graph tasks that existing LLMs, frameworks and agentic systems are unable to achieve. This amplifies the usefulness of LLMs for large-scale private or enterprise knowledge graphs and removes the barrier of leveraging graph analytics libraries.

Experimentally, our new benchmark graph-agent-bench-ln-v0 suggests the agent can already answer many non-trivial graph questions successfully. Our case studies indicate the agent is able to plan and reason for open-ended complex multi-turn tasks. We examined a few challenging scenarios where the current agent struggles.

In the future, we plan to continue adding new tools to the server in the agent to improve its interactions with the LLM. We also plan to expand our benchmarks with additional open-ended complex qeustions, similar to those seen in Section 5, with robust evaluations for such questions. We plan to release new benchmark questions as well as additional benchmark datasets.

While the current agent already exhibits strong capabilities, there are still many open engineering and research challenges remain. Reducing token usage and improving accurate and efficient tool usage remain as important optimisation. Determining the appropriate additional auxiliary tools that ensure they are used in conjunction with the algorithms is an important direction which will improve the agent’s reasoning capability further. The challenges present in this report applies equally to other graph algorithms agents build on top of any graph database and graph data science library. Many of the findings and challenges can be applied to more general non-graph algorithms and other reasoning agents.

Acknowledgments and Disclosure of Funding

The authors thank Jon Besga, Nathalie Charbel, Will Tai and the Neo4j GDS and GenAI team for contributions to developing the prototype and helpful discussions.

Appendix A List of tools in GDS agent

The provide the complete list of the 48 tools as of version 0.5.1. Auxiliary tools:

⬇

count_node, get_node_properties_keys, get_relationship_properties_keys, get_node_labels, get_relationship_types

Centrality algorithm tools:

⬇

article_rank, articulation_points, betweenness_centrality, bridges, CELF, closeness_centrality, degree_centrality, eigenvector_centrality, pagerank, harmonic_centrality, HITS

Community algorithm tools:

⬇

conductance, hdbscan, k_core_decomposition, k_1_coloring, k_means_clustering, label_propagation, leiden, local_clustering_coefficient, louvain, modularity_metric, modularity_optimization, strongly_connected_components, triangle_count, weakly_connected_components, approximate_maximum_k_cut, speaker_listener_label_propagation,

Similarity algorithm tools:

⬇

node_similarity, k_nearest_neighbours

Path finding algorithm tools:

⬇

find_shortest_path, delta_stepping_shortest_path, dijkstra_single_source_shortest_path, a_star_shortest_path, yens_shortest_paths, minimum_weight_spanning_tree, minimum_directed_steiner_tree, prize_collecting_steiner_tree, all_pairs_shortest_paths, random_walk, breadth_first_search, depth_first_search, bellman_ford_single_source_shortest_path, longest_path,

Appendix B Examples tool specification - Yen’s algorithm

⬇

types.Tool(

name="yens_shortest_paths",

description="Yen’s Shortest Path algorithm computes a number of shortest paths between two nodes. The algorithm is often referred to as Yen’s k-Shortest Path algorithm, where k is the number of shortest paths to compute. The algorithm supports weighted graphs with positive relationship weights. It also respects parallel relationships between the same two nodes when computing multiple shortest paths. For k = 1, the algorithm behaves exactly like Dijkstra’s shortest path algorithm and returns the shortest path. For k = 2, the algorithm returns the shortest path and the second shortest path between the same source and target node. Generally, for k = n, the algorithm computes at most n paths which are discovered in the order of their total cost. The GDS implementation is based on the original description. For the actual path computation, Yen’s algorithm uses Dijkstra’s shortest path algorithm. The algorithm makes sure that an already discovered shortest path will not be traversed again."

inputSchema={

"type": "object",

"properties": {

"sourceNode": {

"type": "string",

"description": "Name of the source node to find shortest paths from.",

},

"targetNode": {

"type": "string",

"description": "Name of the target node to find shortest paths to.",

},

"nodeIdentifierProperty": {

"type": "string",

"description": "Property name to use for identifying nodes (e.g., ’name’, ’Name’, ’title’). Use get_node_properties_keys to find available properties.",

},

"k": {

"type": "integer",

"description": "The number of shortest paths to compute between source and target node.",

},

"relationshipWeightProperty": {

"type": "string",

"description": "Name of the relationship property to use as weights. If unspecified, the algorithm runs unweighted.",

},

},

"required": ["sourceNode", "targetNode", "nodeIdentifierProperty"],

},

)

Appendix C graph-agent-bench-got-v1

The Game of Thrones (GoT) dataset contains 2565 nodes and 8923 relationships with different nodes and relationship types as well as properties, as shown in Figure 11.

The questions follow a similar format to graph-agent-bench-ln-v1. A few example questions are listed below.

⬇

Question: Which house has the most Knights? Return the name of the house and nothing else. Return all the top house names if there are ties.

Expected Tool Calls: ["mcp__gds-agent__get_node_labels", "mcp__gds-agent__get_relationship_types", "mcp__gds-agent__get_node_properties_keys", "mcp__gds-agent__degree_centrality"]

Expected Tool Parameters: {"degree_centrality": {"nodeLabels": ["House", "Knight"], "relTypes": ["BELONGS_TO"]}}

Expected Answers: Lannister

Question: If battles and the people who fought in them are organized into three interconnected communities, are Moat Cailin and the Shield Islands battles placed in the same group? Answer Yes or No and nothing else.

Expected Tool Calls: ["mcp__gds-agent__get_node_labels", "mcp__gds-agent__get_relationship_types", "mcp__gds-agent__get_node_properties_keys", "mcp__gds-agent__approximate_maximum_k_cut"]

Expected Tool Parameters: {"approximate_maximum_k_cut": {"nodeLabels": ["Person", "Battle"], "nodeIdentifierProperty": "name", "k": 3}}

Expected Answers: No

Benchmarking results for the agent with different LLM backbones on graph-agent-bench-got-v1 is shown in Figure 12.

The heterogeneity of the graph poses significantly more challenges to the agent compared to the LN underground dataset, as shown by the lower answer accuracy scores. GPT-5 still shows the best results, indicating that there is some notion of a better graph algorithmic understanding. It notably has the highest recall. This suggests that invoking the necessary tools might be the most crucial for obtaining correct final answers, and the fact that redundant information and tool invocation is not detrimental.