DEV Community: Sabika Tasneem

When Should You Use Text2Cypher in a GraphRAG Pipeline

Sabika Tasneem — Fri, 22 May 2026 10:53:33 +0000

Not every GraphRAG question needs the same retrieval pattern.

Some questions need the neighborhood around an entity. Some need a summary across a large part of the graph. Some just need an exact answer from structured data. That last group is where Text2Cypher fits.

It turns a natural language question into a Cypher query, so the system can return a precise graph result instead of a broad summary.

What Is Text2Cypher?

Text2Cypher is the graph version of a broader pattern developers already know from text-to-SQL systems where you take a natural language question and generate a database query that can answer it.

The difference is the target query language.

Instead of generating SQL for tables, Text2Cypher generates Cypher for graph data. Cypher is a declarative query language for property graphs, where data is modeled as nodes, relationships, labels, and properties.

The LLM’s job is not to invent the answer. Its job is to generate the right query, run it, and return the result. That distinction matters.

What Text2Cypher Does in GraphRAG

In a GraphRAG pipeline, Text2Cypher is useful when the user’s question maps cleanly to the graph schema.

For example:

Does user 31254 exist in this dataset?
Which suppliers provide components used in Product A?
How many orders are delayed by more than 7 days?
Which customers have more than 3 unresolved support tickets?

These questions are not asking the model to read a pile of text and summarize it. They are asking for a structured answer from structured data.

A practical Text2Cypher flow usually looks like this:

Inspect the graph schema.
Pass the relevant schema context to the LLM.
Generate the Cypher query.
Run the query.
Return the result.

Schema is the part people underestimate.

If the LLM does not know what labels, relationship types, and properties exist, it can generate a query that looks reasonable but does not match the actual graph. For example, it may generate (:Customer)-[:PURCHASED]->(:Product)when the real graph uses (:User)-[:BOUGHT]->(:Item).

That query is syntactically fine. It is just wrong for your data.

In Memgraph, SHOW SCHEMA INFO can expose labels, relationship types, and properties, giving the model real schema context before it generates the query.

Why Text2Cypher Is the Best Fit for Analytical GraphRAG Questions

Analytical GraphRAG questions ask for something concrete.

Usually, the answer is one of these:

A count
A boolean answer
A list of matching nodes
A filtered table
A grouped result
A ranked result based on a property or aggregate

For example, in a GitHub Issues knowledge graph, a user might ask:

How many feature requests Memgraph has?

That question does not need the model to retrieve five chunks about issue tracking and reason from prose.

It needs a query over the graph:

SHOW SCHEMA INFO;

MATCH (i:Issue)
RETURN i.issue_type AS issue_type,
       count(*) AS count
ORDER BY count DESC;

That answer comes back as a table shaped result.

No long context window. No vague summary. No pretending that a generative answer is better than a database result.

That is why Text2Cypher is a strong fit for analytical GraphRAG. The question has a query-shaped answer.

When Text2Cypher Is the Wrong Tool

Text2Cypher gets weaker when the question is open-ended, exploratory, or depends on broader context that does not live in a single clean query result.

Bad fits include questions like:

Why are users unhappy with this product?
What themes appear across negative reviews?
Which related issues should an engineer investigate first?
What is missing from this research corpus?

These questions need more than a count or table.

They may need local graph search, where the system starts from a relevant node and expands into its surrounding neighborhood. Or they may need query-focused summarization, where the system synthesizes patterns across a larger part of the graph.

Trying to force Text2Cypher onto those questions gives you shallow answers.

A query can return rows. It does not automatically explain themes, tradeoffs, causes, or missing context.

A useful rule is simple:

If the Answer Should Look Like...	Use...
A number, table, filtered list, or direct lookup	Text2Cypher
Connected context around one entity	Local graph search
Themes or patterns across a corpus	Query-focused summarization

The retrieval path should match the question.

Keep the Pipeline Inspectable

Text2Cypher has one major advantage for developers: you can inspect it.

You can read the generated query and you can run it again. That matters in GraphRAG because retrieval bugs are easy to hide behind fluent language.

If the answer is wrong, you need to know where the failure happened. Was the schema context incomplete? Did the model generate the wrong query? Did the graph lack the right data? Did the final LLM response overstate what the query returned?

For analytical retrieval, the cleanest pipeline is often the most boring one: inspect the schema, generate the query, execute it, and return the result.

That is also what makes Text2Cypher easier to evaluate than a retrieval flow hidden behind several prompts and orchestration steps. The generated query gives you something concrete to inspect before the final answer reaches the user.

For a deeper walkthrough of this pattern, Memgraph has a full guide on Text2Cypher for GraphRAG analytical questions.

Text2Cypher is not the whole GraphRAG story. It is the pattern you use when the question has a query-shaped answer.

When Should You Use GraphRAG Instead of RAG?

Sabika Tasneem — Thu, 21 May 2026 10:36:08 +0000

Most teams building LLM applications start with RAG for a good reason. It is practical, easy to understand, and usually good enough for a simple AI use case.

But once users stop asking simple lookup questions and start asking relationship-heavy questions, standard RAG can get shallow fast.

The issue is not that RAG is bad. The issue is that many real questions are not just about finding a relevant paragraph. They are about following connections across people, products, systems, documents, events, or dependencies.

That is the gap GraphRAG tries to fill.

RAG vs GraphRAG

RAG made LLM applications more useful because it gave models access to external information.

Instead of asking a model to answer from training data alone, a RAG pipeline retrieves relevant content from your docs, tickets, wikis, PDFs, or databases, adds that content to the prompt, and asks the model to answer from it.

That works well for a lot of use cases.

If the question is:

What is our refund policy for annual subscriptions?

A standard RAG pipeline can search the documentation, find the right policy section, and give the model the relevant text.

The problem starts when the question is not just about finding the right text. It starts when the answer depends on relationships.

For example:

Which suppliers could be causing delivery delays for products affected by a specific component shortage?

That question is not just asking for a matching paragraph. It needs the system to connect suppliers, components, products, shipments, delays, and dependencies.

This is where GraphRAG becomes useful.

RAG is good at finding text that sounds relevant. GraphRAG is better when the answer depends on how things are connected.

What RAG Does Well

Retrieval augmented generation, usually shortened to RAG, combines a language model with an external retrieval system. The original paper described this as combining a parametric model (the LLM itself) with non-parametric memory (external knowledge), usually retrieved from an external corpus.

In most modern implementations, that retrieval step uses embeddings. The basic flow looks like this:

Split documents into chunks.
Convert each chunk into an embedding.
Store those embeddings in a vector index.
Convert the user question into an embedding.
Retrieve the most similar chunks.
Add those chunks to the LLM prompt.
Generate the answer.

This is useful when the answer is likely to be contained in one or a few text chunks. Good RAG use cases include:

Documentation search
FAQ assistants
Internal knowledge base search
Customer support answer generation
Summarization over a small set of relevant documents

For many teams, this is the right starting point. It is simpler than building a knowledge graph, and it can deliver useful results quickly.

The issue is that similarity is not the same as understanding.

A vector search system can find chunks that sound close to the query. It does not automatically know whether one entity owns another, depends on another, contradicts another, or affects another through a multi step chain.

That difference matters once your questions become relational.

Where RAG Gets Shallow

RAG usually retrieves isolated text chunks. That creates a few common problems.

First, chunking can break context. A policy, customer, transaction, or technical decision might make sense only when you see how it connects to other facts. Splitting documents into chunks can hide that structure.

Second, semantic similarity can over retrieve. A chunk may sound relevant without being useful for the actual answer.

Third, RAG does not inherently reason across relationships. It may retrieve text about a supplier, text about a product, and text about a shipment delay, but it does not automatically know how those things connect.

Think about this question:

Which customers are affected by the delayed shipment from Supplier A?

A standard RAG pipeline might retrieve documents that mention Supplier A, delayed shipments, and customers. That is helpful, but still incomplete.

The actual answer may require a path like this:

Supplier A -> supplies -> Component X -> used in -> Product Y -> included in -> Shipment Z -> assigned to -> Customer C

That path is not just text similarity. It is structure.

If your application needs to answer questions like this, treating your knowledge base as flat chunks is a weak model of the problem.

What GraphRAG Adds

GraphRAG keeps the useful part of RAG: retrieval. But it adds a graph layer, where information is represented as entities and relationships. Microsoft’s paper on GraphRAG for query focused summarization helped popularize this pattern for using graph structure to answer questions that need broader connected context.

Instead of only storing chunks like:

Supplier A provides Component X. Component X is used in Product Y. Product Y is part of Shipment Z.

A graph represents the structure directly:

(Supplier A)-[:SUPPLIES]->(Component X)
(Component X)-[:USED_IN]->(Product Y)
(Product Y)-[:INCLUDED_IN]->(Shipment Z)
(Shipment Z)-[:ASSIGNED_TO]->(Customer C)

Now the system can retrieve context by following relationships, not just by matching similar text.

A GraphRAG pipeline might work like this:

Use semantic search, keyword search, or another method to find a starting point.
Identify the relevant node or set of nodes in the graph.
Traverse connected relationships.
Rank, filter, and compress the connected context.
Send the final context to the LLM.

The key difference is that search finds where to start, while graph traversal finds what is connected.

That is why GraphRAG is useful for relationship-heavy use cases, such as:

Supply chain analysis where the system needs to trace products, components, suppliers, and delayed shipments
Fraud detection where suspicious behavior appears across shared accounts, devices, transactions, or addresses
Cybersecurity investigation where alerts need to be connected to users, assets, permissions, and attack paths
Healthcare or life sciences research where answers depend on relationships between diseases, genes, drugs, and clinical evidence
Customer 360 applications where support tickets, purchases, product usage, and account history need to be connected

These are not just document lookup problems. They are relationship problems.

RAG and GraphRAG Are Not Enemies

The lazy version of this topic is: RAG bad, GraphRAG good.

That is wrong. RAG is still useful. If your data is mostly unstructured text and your questions are direct, a standard RAG pipeline may be enough. GraphRAG becomes useful when the shape of the answer depends on connected facts. A better way to think about it:

Use RAG When	Use GraphRAG When
The answer is likely inside a small number of text chunks.	The answer depends on relationships across entities.
You need fast document Q&A.	You need multi-hop reasoning.
Your data does not have strong entity relationships.	Your data has dependencies, hierarchies, ownership, or causality.
You are building a first version quickly.	You need more explainable and structured retrieval.

In practice, many good systems use both. Vector search can find semantically relevant entry points. Graph traversal can expand from those entry points into connected context.

That combination is often more useful than either approach alone.

Keep the Retrieval Logic Close to the Data

GraphRAG gets harder to maintain when every retrieval step lives in a different place.

One service finds similar chunks. Another stores the graph. Another expands relationships. Another ranks results. Another builds the final prompt.

That can work, but it gives you more moving parts to debug when the answer is wrong.

A cleaner pattern is to keep as much of the retrieval logic as possible close to the graph itself. Search can find the starting point. Traversal can expand the context. Ranking and filtering can reduce the result before it ever reaches the prompt.

That is the idea behind Atomic GraphRAG in Memgraph. It express the retrieval path as a single execution layer where possible, instead of spreading it across a pile of orchestration code.

The broader lesson is not tool specific. If your GraphRAG pipeline is hard to inspect, it will be hard to trust. The retrieval path should be visible, testable, and easy to change.

The Practical Rule

Use RAG when you need to retrieve relevant text. Use GraphRAG when you need to retrieve connected context. That is the real distinction.

If your question can be answered by finding the right paragraph, RAG is probably enough. If your question requires following relationships between people, products, systems, documents, events, risks, or dependencies, you are no longer just doing text retrieval. You are doing graph retrieval.

The point is not to use GraphRAG as an extra layer and start using it where it is right retrieval model for the problem.

MCP for Agents: The Security Gap Most Teams Miss

Sabika Tasneem — Mon, 16 Feb 2026 12:31:41 +0000

MCP is exciting because it turns an LLM into something that can execute actions through tool calls. One protocol, many tools. Your agent can pull data, update tickets, call APIs, and trigger workflows. That is exactly why teams are rushing to ship MCP based agents.

That speed comes with a tradeoff. Once an LLM can touch live systems, mistakes stop being “bad answers” and start becoming real actions. The point of this post is not to criticize MCP. It is to help you ship agents that stay useful without unintentionally expanding your blast radius.

Let’s dive in!

What MCP Gives You (And What it Does Not)

MCP standardizes how tools and context are exposed to a model, which is great for developer velocity. What it does not do is decide what is safe or appropriate in your environment. You still own boundaries and behavior.

In production, the gaps show up fast:

Which tool should be used for this request
What data is allowed for this user or team
Which actions should be blocked or require approval
How you can audit tool use after something goes wrong

If you want the spec level overview, start with Anthropic’s MCP introduction.

Building Agents with MCP: 3 Problems You Will Hit First

The first failure is rarely a headline breach. It usually looks like a normal product bug, except now the bug can trigger emails, update records, or touch production data. For instance:

The Agent Does the “Helpful” Thing You Did Not Ask For

A user asks, “Can you check which customers are impacted?” The agent decides that notifying customers is helpful and drafts a mass email. Nothing was hacked. The model was just optimizing for task completion, and you gave it a tool that made the wrong idea easy.
A Demo Tool Becomes a Production Hazard

Most teams start with a broad tool set because it makes the demo work. Later, the agent gets a slightly different question and reaches for the most powerful tool available. If that tool can write, delete, or trigger workflows, you now have an outsized failure scope. That is the blast radius.
The Agent Guesses and Guesses Wrong

If your agent can query a database, it will try. If it does not have the right context about what is allowed and what the data means, it will guess. Sometimes the guess is harmless. Sometimes it pulls data it should not have pulled, or it produces results that look right but are based on the wrong assumptions.

Why Prompt Rules Are Not Enforcement

The common response is to add more instructions: “Read-only,” “confirm before sending,” “never delete.” Those rules help, but they do not enforce anything.

There is a simple reason. Prompts influence the model’s behavior. They do not change the system’s capabilities. If a write tool is exposed, the model can still call it, even if you told it not to. If a broad SQL tool is exposed, the model can still retrieve more data than you intended, even if you asked it to be careful.

This is why prompt-only safety tends to decay over time. As you add tools, edge cases, and new workflows, the instruction layer becomes a long list of exceptions. The agent still has the same tool surface, but now it is operating under a growing set of text rules that are easy to miss, conflict, or misapply.

The fix is capability control. Reduce what the agent can do, scope what it can see, and require explicit approvals for actions that have a real blast radius.

The Practical Fix: Shrink the Tool Surface at Runtime

Do not rely on the model to always choose correctly. Make wrong choices harder. The simplest way to do that is to reduce what the agent can do by default, then expand capabilities only when you have a clear reason.

Start with these guardrails:

Expose fewer tools by default
Only expose tools that match the current task
Separate read tools from write tools
Require approvals for irreversible actions
Log tool calls so you can trace what happened

This is least-privilege design applied to agent tool access, enforced at runtime.

Where GraphRAG Fits in an MCP Tooling Stack

Most RAG stacks start with vectors. Vectors are great at finding semantically similar text, but they are not built to represent relationships like who owns which data, which rule is current, or which tool is allowed for this workflow.

Graphs are good at that because they model relationships directly. When you add a graph-based context layer, you can give the model a smaller, cleaner slice of context tied to the user and the task.

For example, you can make use of label-based access controls that determine which node labels and relationship edge types a given user or workflow can touch. That reduces overload and lowers the chance your agent reaches for the wrong tool.

A Checklist You Can Actually Use

If you are shipping MCP-powered agents, do not treat guardrails as a final polish step. Treat them as part of the build. The fastest way to end up in trouble is to bolt safety on after you have already exposed a wide tool surface to an LLM.

Start with a simple baseline and improve it as you learn. The point is not to predict every edge case up front. The point is to make tool behavior observable, reversible where possible, and scoped to what the agent should be doing right now.

If you are shipping MCP-powered agents, start here:

List your tools and label them read or write
Turn off anything irreversible by default
Add a human approval step for high impact actions
Keep tool descriptions short and specific
Log every tool call with who requested it and what tool ran
Review misfires weekly and treat them as product bugs

This checklist is not about paranoia. It is about making MCP workflows predictable enough to ship. If your plan is “we will fix it in the prompt,” you are in for some trouble.

What Memgraph adds to an MCP agent stack

At some point in production, most enterprise teams realize they need a real context layer. Memgraph is an in-memory graph database used as a real-time context engine, which makes it a good fit when your agent needs fast traversal, connected context, and governance that changes as your systems change.

In practice, you can use Memgraph to store and query the relationships your agent depends on, then apply GraphRAG patterns to retrieve a connected context slice instead of stuffing everything into a prompt.

This is also where Memgraph’s Atomic GraphRAG comes in. Instead of stitching together multiple retrieval steps in your application code, Atomic GraphRAG aims to generate context in a single query so it is simpler, faster, and easier to review and tweak.

For you, that means fewer moving parts, clearer failure modes, and a smaller surface area for accidental tool misuse.

If you are exploring MCP specifically, Memgraph provides an MCP Server to expose graph context to agents, and an MCP Client inside Memgraph Lab to compose workflows across MCP servers.

Wrapping Up

MCP is a doorway to useful agents. It also makes mistakes expensive. If you want to ship responsibly, focus on runtime guardrails: shrink the tool surface, keep context clean, and log everything.

If you want to explore a graph-based context layer for MCP, start here. And remember, tool access is part of your attack surface, so review it alongside your production code.