DEV Community: Syed Zadi

What Is GraphRAG? A Plain English Explainer

Syed Zadi — Wed, 21 Oct 2026 05:00:00 +0000

GraphRAG is retrieval-augmented generation where the retrieval layer queries a knowledge graph not, or not only, a vector database.

Instead of returning similar text chunks, it returns typed entities and the relationships between them. The LLM then answers from structured, citable facts rather than statistical guesses about which paragraph looked relevant.

RAG in one paragraph, then what GraphRAG adds

Retrieval-augmented generation grounds an LLM answer in retrieved evidence. The standard recipe: chunk your documents, embed them with a model, store the embeddings in a vector database. At query time, embed the user's question, find the most similar chunks, pass them to the LLM as context.

This works beautifully for "summarize this document" and "find me a policy that says X."

It falls apart the moment the answer requires composing facts from multiple entities or systems.

A knowledge graph stores your business as typed entities customers, contracts, products, incidents connected by typed relationships. When a user asks a question, the retriever can walk the graph (customer → contract → clause → obligation) to compose the actual answer, then hand the LLM the resulting facts with pointers to the source systems they came from.

Three concrete failures GraphRAG fixes

Hallucination on multi-hop questions.

"Which of our Platinum plan customers raised P1 tickets about the feature we deprecated last quarter?"

No single document contains that answer. Vector search returns chunks that look related and the LLM fabricates the join. GraphRAG returns the exact list, with citations to the source system for each row.

Fabricated citations in high-stakes domains.

Legal and clinical assistants built on pure vector RAG keep inventing cases and papers. When retrieval returns a typed entity with a real identifier, there is nothing to invent the citation is the node.

Answers that go stale silently.

Vector chunks do not know that a policy was superseded. A graph can model supersession as an edge and exclude the retired version by traversal, rather than hoping the stale chunk ranks lower.

The five layers of a GraphRAG system

Layer	What it does
Ontology	Defines the entity types and relationship types your domain actually has
Ingestion	Extracts entities and relationships from source systems and documents
Graph store	Holds the typed nodes and edges; Neo4j is the common choice
Hybrid retrieval	Combines graph traversal with vector search over node text
Evaluation	Measures whether retrieved context actually supports the answer

The ontology is the part teams underestimate. It is a modeling exercise about your business, not a database schema task, and getting it wrong is the most expensive mistake in the stack.

The evaluation layer is the part teams skip. Without it you cannot tell a retrieval regression from a model regression.

When to use GraphRAG and when not to

Use it when:

Answers require composing facts across multiple entities or systems
You need counting, aggregation, or absence ("which accounts have no owner?")
Citations must point to systems of record, not paragraphs
Permissions are relationship-shaped and cannot be expressed as one filter
Content gets superseded and stale answers are harmful

Do not use it when:

Your corpus is a document pile and the questions are "summarize" or "find the policy that says X"
Access control is effectively open, or expressible as a single filter
Nothing in your source data gets reversed or superseded later

If all three of those hold, plain vector search is sufficient and considerably cheaper to run. Internal enterprise search over operational data almost never satisfies all three at once which is why the question keeps coming up.

For the full decision framework, see GraphRAG vs vector RAG.

We build enterprise GraphRAG systems on Neo4j. If you are deciding whether your stack needs one, talk to our team.

How to Build an MCP Server in Next.js

Syed Zadi — Tue, 20 Oct 2026 10:35:00 +0000

To build an MCP server in Next.js, you expose a single API route that speaks the Model Context Protocol over Streamable HTTP. It accepts the client's JSON-RPC requests, dispatches each one to a registered tool, and streams results back.

That is the whole shape. The interesting part is everything around it.

What you are actually building

An MCP server is a governed adapter. It gives an AI client scoped, audited access to your tools and data instead of pasting raw API keys into a prompt and hoping.

The route handler is the surface the AI client connects to. Behind it sit the tool implementations that actually touch your systems.

If that framing is new, start with what an MCP server is and come back.

Pick the transport: HTTP, not stdio

MCP defines two transports.

stdio is for a local subprocess the client spawns the server as a child process and talks over standard input and output. Useful for desktop tooling, wrong for a web app.

Streamable HTTP is for a remote server reached over the network. That is what a Next.js route is.

Choose HTTP. It lets many clients connect, and it sits behind the same authentication, rate limiting, and observability you already run in front of your app. You do not have to invent a second operational stack for your AI surface.

A minimal route handler

The shape is a POST handler that:

Authenticates the caller
Parses the JSON-RPC request
Dispatches to the right tool
Returns the result

// app/api/mcp/route.ts
export async function POST(req: Request) {
  const caller = await authenticate(req);   // 1
  if (!caller) return new Response("Unauthorized", { status: 401 });

  const rpc = await req.json();             // 2
  const tool = TOOLS[rpc.params?.name];     // 3
  if (!tool) return jsonRpcError(rpc.id, -32601, "Method not found");

  const args = tool.schema.parse(rpc.params.arguments);
  const result = await tool.run(args, caller);

  return Response.json({                    // 4
    jsonrpc: "2.0",
    id: rpc.id,
    result,
  });
}

Note what happens before any tool runs: the caller is authenticated, and the arguments are parsed against a schema. Neither step is optional.

Exposing tools without handing out the keys

A tool is a named, typed function the model may call.

The temptation is to expose a thin passthrough to an internal API. The discipline is to expose the capability, not the API.

A passthrough tool called callInternalApi(path, method, body) is not a tool. It is a remote shell with extra steps. The model can reach anything the service account can reach, and your audit log records "called the API" rather than "read customer 4821's billing status."

Three rules that hold up in production:

The server holds its own scoped credentials. The model never sees a key. Each tool runs with the narrowest permission that does its job.

No tool is "run arbitrary query." If a tool accepts SQL, Cypher, or a shell string, you have built an injection surface that no amount of prompting will close.

Every input is validated at the boundary. A model or a prompt injection riding inside retrieved data will eventually send something malformed or hostile. Parse with a schema, reject on failure, and log the rejection.

What changes in production

The demo works on your laptop. These are what break first when it does not.

Concern	What to add
Authentication	Per-caller identity, not a shared secret
Authorization	Permission check inside each tool, not just at the route
Rate limiting	Per caller and per tool agents retry aggressively
Timeouts	Every downstream call needs one; agents will hang otherwise
Audit logging	Caller, tool, arguments, result, timestamp immutable
Error shape	Return structured JSON-RPC errors, never raw stack traces

The last one matters more than it looks. A stack trace returned to a model becomes context the model reasons over, and leaks your internals into whatever the agent does next.

Where to go next

Once the route is live, the real work is tool design deciding what each tool exposes and, more importantly, what it refuses to.

That is a security question more than an engineering one. MCP server security covers the threat model and a hardening checklist to run before anything touches a system of record.

We build production MCP servers for regulated industries. If you are shipping one, talk to our team.

What Is an MCP Server? An Enterprise Guide

Syed Zadi — Mon, 19 Oct 2026 12:30:46 +0000

Every AI agent needs data. The question is whether it gets that data through a governed, auditable channel or through a raw database connection your security team has never reviewed.

That is the problem the Model Context Protocol (MCP) solves. And the MCP server is the component that sits between your enterprise systems and the AI model.

What is an MCP server?
An MCP server is a lightweight process that exposes a specific slice of your data or tooling to an AI agent through a standardized protocol. Anthropic introduced MCP in 2024 as an open standard, and it has since been adopted across the AI industry.

Think of it this way: if MCP is USB, the MCP server is the device you plug in a camera, a keyboard, a drive. Each server does one thing and declares exactly what it offers.

Three pieces make up an MCP integration:

Host: The AI application (Claude Desktop, your custom agent, an IDE)
Client: Maintains a 1:1 connection with a single server
Server: Exposes tools, resources, and prompts from one data domain
Why the protocol exists
Before MCP, every AI integration was a custom REST wrapper. A LangChain tool calling your CRM looked nothing like a LangChain tool calling your ERP. Every new data source meant a new integration pattern, a new auth flow, a new set of failure modes.

MCP replaces that with a single contract: the server declares its capabilities, the client discovers them at runtime, and the model calls them through a typed interface. One pattern, regardless of what sits behind the server.

For enterprises, this matters because:

Security teams can audit a finite surface not an unbounded set of custom integrations
New data sources plug in without rebuilding the agent add a server, the agent discovers it
Vendor lock-in drops swap the model, keep the servers
Host, client, and server
The host is the application the user interacts with. The client is the connection manager one client per server, maintaining session state and handling the handshake. The server is where your logic lives.

This separation matters operationally. A server can be restarted, versioned, or replaced without touching the host application. A new model can be swapped into the host without rewriting a single server.

Why enterprises build custom servers
Public MCP servers exist for common tools GitHub, Slack, Postgres. They are useful for prototyping and nearly always wrong for production.

The reason: a generic Postgres MCP server exposes arbitrary SQL. That is exactly what you do not want an AI model holding. A production server exposes operations, not access.

At Agentic Giants we build one server per data domain. A real deployment might look like:

Server What it exposes What it does NOT expose
Task Server Task creation, status, assignments Raw database queries
File Server File metadata, upload/download File system paths
User Server User profiles, roles Password hashes, tokens
Activity Server Audit logs, events PII without masking
Each server enforces its own access controls. The model never sees raw infrastructure it sees a curated, permission-scoped interface.

What makes an MCP server safe
Four principles separate a production MCP server from a demo:

Least privilege per tool. Each tool declaration specifies exactly which parameters it accepts and which data it returns. The model cannot improvise a query or reach a field the server does not expose.

No raw query composition. The server translates structured requests into backend queries. The model asks for "tasks assigned to user X in the last 7 days" the server builds and executes the query. SQL injection becomes structurally impossible, because the model never composes SQL.

Immutable audit logs. Every tool call, every parameter, every response logged and traceable. When compliance asks "what did the AI access?" you have a complete answer, not a reconstruction.

Human in the loop. MCP supports approval flows. High-risk operations deleting data, sending external communications, moving money can require explicit human confirmation before the server executes.

How many servers do you need?
One per data domain is the pattern that works. Not one per table, and not one monolithic server for everything.

Too few servers and you have a god-object problem: one server with broad access is one server with a broad blast radius. Too many and you pay orchestration overhead on every request.

For most enterprises, 5–15 servers cover the full data landscape. Our largest production deployment runs ten servers, one per data domain, and has been stable for ninety days.

Getting started
If you are evaluating MCP for your enterprise:

Map your data domains CRM, ERP, document store, task management
Pick the first high-value agent use case usually internal knowledge retrieval or task automation
Build one server for that domain get it into production, learn the operational patterns
Expand one domain at a time each new server is additive, never a rewrite
The protocol is open and the specification is at modelcontextprotocol.io. The enterprise question is not whether to adopt MCP — it is how to build servers your security and compliance teams will actually approve.