Database Agents with MCP and LangChain

Overview

A guide to architecting production-grade database agents by fusing the Model Context Protocol (MCP) for standardized tool communication with LangGraph for stateful agent orchestration — covering context provisioning strategies and the defense-in-depth security posture required before letting an LLM execute queries against a real database.

The MCP Foundation

MCP is an open standard that solves the M×N integration problem: instead of custom connectors for every model-to-tool pair, it creates a universal interface, turning the problem into a scalable M+N solution — the “USB-C for AI.” It uses a client-server architecture: MCP clients (AI agents) initiate requests, MCP servers expose APIs, tools, or data sources. Core primitives are Tools (executable functions), Resources (structured data streams), and Prompts (reusable instruction templates).

A minimal MCP database server exposes three tools: list_tables(), get_schema_for_tables(), and execute_safe_query() — the last hardcoded to reject anything that isn't a SELECT statement.

The LangGraph Brain

LangChain evolved from simple chains to LangGraph, a framework for stateful, cyclic agents giving developers explicit control over the reasoning loop: explicit state (exactly what the agent carries between steps), cyclic workflows (multi-step reasoning that can adapt and recover from errors), and full observability for production use. A typical graph defines an AgentState, wires a SQL toolkit into a ReAct agent, and loops between a reasoning node and a tool-execution node until a final answer is reached.

Mastering Context Provisioning

SQL generation quality is entirely dependent on the context given to the LLM. Four techniques, each with distinct trade-offs:

Technique	Pros	Cons
Prompt Engineering	Simple for small, stable schemas; fine-grained control	Unmanageable at scale; exceeds token limits; hardcoded
Database Comments	Metadata lives with the data, version-controlled	Needs DB modification rights; limited expressiveness
RAG on Documentation	Handles vast unstructured context; decouples docs from prompt	Adds architectural complexity; retrieval errors possible
Curated Views	Drastically simplifies schema reasoning, improves accuracy	High setup/maintenance effort; limits ad-hoc flexibility

Beyond the table-level techniques, four complementary strategies compose into a full pipeline: Dynamic Schema Selection (only retrieve schema for tables relevant to the query), Semantic Layer (enrich raw schemas with business context), Few-Shot Prompting (dynamically select similar question/SQL example pairs), and Error Correction Tools (retriever tools that catch misspellings in high-cardinality columns before SQL generation). The key strategy: it's not about providing more information, it's about providing the right information at the right time — schema discovery → semantic enrichment → few-shot guidance → error correction.

The Integrated Architecture

LangGraph acts as the orchestration “brain,” MCP as the standardized “nervous system” connecting to tool “limbs.” End-to-end flow: User Interface → LangGraph Agent (Brain) → MCP Client → Custom MCP Server (Limb) → Database. This separation of concerns lets orchestration logic and tool implementation scale and update independently, and any MCP-compliant tool can plug into any LangGraph agent.

Productionization & Security

Executing LLM-generated code against a database is inherently risky — a production system needs defense-in-depth across every layer, since prompt instructions alone are not enough:

Layer	Control	Rationale
Database	Strict read-only permissions (dedicated SELECT-only user)	The most critical line of defense
Database	Row-level security / views	Enforces “need-to-know” data segregation
Application	Keyword filtering (reject DELETE/DROP/UPDATE)	Deterministic failsafe, immune to prompt injection
Application	Pre-execution validation (e.g., LangChain's QuerySQLCheckerTool)	Cost-effective circuit breaker for syntax errors
LLM	Prompt-level guardrails	Hardens default model behavior
Access	User-based context filtering	Prevents the LLM from seeing unauthorized data structures

Key Takeaways

The article's central design principle is that MCP and LangGraph solve two genuinely different problems — MCP standardizes how an agent talks to tools, LangGraph governs when and why it decides to call them — and treating them as substitutes rather than complements is the mistake the “brain and nervous system” framing is meant to head off.
Context provisioning is presented as a pipeline, not a single technique choice: the four table-level strategies (prompt engineering, comments, RAG, curated views) address what metadata exists, while dynamic selection, semantic layering, few-shot examples, and error correction address when and how much of it reaches the LLM — conflating these two concerns is what causes both token-limit blowouts and hallucinated columns.
The security section's core argument is that no single layer is sufficient on its own — prompt-level guardrails are explicitly framed as the weakest control (model behavior, not a hard constraint), which is why database-level read-only permissions are called the most critical line of defense: the layers are ordered by how hard they are to bypass, not how easy they are to implement.