Adding Legal Research to Your AI Agent with MCP

How to Add Legal Research to an AI Agent with MCP

Short answer: to add legal research to your AI agent, connect it to a legal research MCP server. The server exposes statute tools the agent can call (statute search, section text, citation resolution across US Code, CFR, and 50 state codes) so it pulls real US law instead of generating it from memory. Install the server, set an API key, register the tools with your agent framework, and the agent now grounds every legal claim in a real source. The walkthrough below shows the full config, a real agent run, and the architecture patterns that hold up.

Every developer building AI agents runs into the same wall eventually: the agent can reason, plan, and chain tool calls together, but the moment it tries to do legal research, it falls apart. It makes up case names. It invents citations. It quotes opinions that don't exist.

And it does all of this with absolute confidence. The fix is to add legal research to your AI agent via MCP, so the agent calls a real database instead of guessing.

This isn't a model problem. GPT, Claude, Gemini, every foundation model hallucinates legal citations. The training data includes some case law, but not enough to be reliable, and definitely not enough to be citable.

How often does it happen? The Stanford study "Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools" (Magesh et al., preprint at arXiv:2405.20362, 2024) found purpose-built legal AI tools still hallucinate on 17 to 33 percent of queries, while general chatbots hallucinate on legal questions far more often. Grounding the agent in a real source is what closes that gap.

Lawyers have been sanctioned for filing briefs full of fake ChatGPT citations that read perfectly and pointed to nothing. You wouldn't build a financial agent that guesses stock prices instead of calling a market data API. Legal research should work the same way.

The Model Context Protocol (MCP) fixes this by giving agents a clean interface to external data sources. Instead of generating legal text from memory, your agent calls tools that hit a real statutes database.

The answer comes back grounded in actual primary law, with real citations, from a real legal source.

TL;DR

• The problem: foundation models invent citations; never let an agent cite from memory.
• The fix: add legal research to your AI agent via MCP. Install uvx vaquill-mcp, set the API key, and the agent gets statute search, section text, and citation tools that hit real US law instead of hallucinating.
• What the MCP tools cover: statutes search and section text (USC, CFR, 50 state codes) via the public statutes API, plus statute-citation resolution, so the agent can find and quote the operative text against a real source.
• What the public REST API does: statutes and legislation only (USC, CFR, Federal Rules, 50-state codes, state constitutions, state court rules, Executive Orders since 2015). It does not return case law, opinions, or AI answers.
• The payoff: the agent answers "what does 5 U.S.C. 706 say?" or "when is copying fair use under 17 U.S.C. 107?" with the verified operative text instead of a confident guess.
• Patterns covered: research, drafting, due diligence, and compliance-monitor agents, plus error handling for missing or ambiguous inputs.

Part of our MCP and developer guide series.

For related MCP / API / developer coverage, see How to Use Claude for US Legal Research (with MCP) and Legal Research from Inside Cursor and Claude Code: The MCP Way.

I'm Priyansh, CTO of the team that built this MCP server. Scope note up front, because this is exactly where developer posts confuse readers: the public REST API and the MCP server are statutes and legislation only (USC, CFR, Federal Rules, 50-state codes, state constitutions, state court rules, Executive Orders since 2015). They do not return case law, opinions, or AI answers.

Case-law research and grounded AI answers are features of the Vaquill AI product itself, used inside the app, not endpoints exposed by the public API or the MCP server. This post is about wiring the statutes tools into an agent.

With that out of the way, this is for developers building agents programmatically. The walkthrough below covers what each tool does, how to wire it in, and the architecture patterns that hold up in real research workflows. For an end-user guide on Claude Desktop or Cursor, see the Claude for US legal research tutorial.

The MCP Tools

The server is a statutes surface: documented, versioned, and supported. It covers the U.S. Code, the CFR, all 50 state codes, state constitutions, state court rules, the Federal Rules, and Executive Orders since 2015. Build against these tools and they will keep working.

Case-law research and grounded AI answers live in the Vaquill AI product, used inside the app. They are not endpoints the MCP server or the public REST API exposes, so this walkthrough wires in the statutes tools.

search_us_statutes

Public statutes REST API: USC, CFR, 50-state codes. Search the U.S. Code, the CFR, and all 50 state statute codes. When the agent knows the legal concept or provision it's after, search_us_statutes returns matching sections with titles, citations, and snippets.

A query like "warrantless search" surfaces the relevant criminal-procedure provisions; "qualified immunity" points you toward 42 U.S.C. 1983; copyright work lands on 17 U.S.C. 107.

From an agent architecture perspective, this is the workhorse for finding the operative statutory language before reasoning about it. The results are structured and deterministic, which is exactly what feeds the next step of a chain.

get_us_statute_section

Public statutes REST API: USC, CFR, 50-state codes. Pull the full text of a specific statutory section by citation. Hand it "42 U.S.C. 1983" or "5 U.S.C. 706" and it returns the operative language plus metadata.

This is how an agent quotes the controlling text verbatim instead of paraphrasing it from memory.

This is the single most important tool for grounding statutory claims. Every section the agent cites should be pulled through get_us_statute_section so the quoted language is the real text, not a plausible reconstruction.

get_pricing

Public endpoint. Check current API credit pricing. This endpoint requires no authentication.

Useful if the agent needs to estimate costs before executing an expensive workflow, or if you're building a user-facing tool that shows credit consumption. This is a housekeeping tool, not a research tool, but it matters for agents that manage budgets.

Installation

The MCP server is a Python package published on PyPI. Install it globally or run it with uvx:

pip install vaquill-mcp
# or run without installing
uvx vaquill-mcp

You need one environment variable:

export VAQUILL_API_KEY=vq_key_your_key_here

Get an API key from app.vaquill.ai. New accounts get 500 free credits on signup, enough to build and test with.

Connecting from Your Agent Code

The setup instructions for Claude Desktop, Cursor, and VS Code are covered in the end-user tutorial. This section focuses on what developers need: programmatic access from agent code.

Using the MCP Client SDK

If you're building your own agent, connect to the MCP server using the MCP client SDK. Here's a minimal Python example:

from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client

server_params = StdioServerParameters(
    command="uvx",
    args=["vaquill-mcp"],
    env={"VAQUILL_API_KEY": "vq_key_your_key_here"}
)

async with stdio_client(server_params) as (read, write):
    async with ClientSession(read, write) as session:
        await session.initialize()

        # List available tools
        tools = await session.list_tools()
        print([t.name for t in tools.tools])

        # Call a tool
        result = await session.call_tool(
            "search_us_statutes",
            arguments={
                "query": "warrantless search",
            }
        )
        print(result)

This is the pattern you'd use inside an agent framework like LangGraph, CrewAI, or a custom orchestration layer. The MCP SDK handles the transport; your agent decides when and how to call each tool.

Integrating with LangGraph

If you're using LangGraph, the MCP tools map naturally to LangGraph's tool-calling nodes. Each MCP tool becomes a node in your graph, and you define edges based on the research workflow you want. For example:

search_node → section_text_node → synthesize_node

The key insight is that MCP tools are stateless. Your agent graph manages the state (which sections have been found, which text has been pulled), and each tool call is a pure function that takes inputs and returns structured data.

Integrating with CrewAI

CrewAI agents can use MCP tools directly as agent tools. Define a "Statute Researcher" agent that has access to search_us_statutes and get_us_statute_section, and a "Drafting" agent that consumes the pinned text.

The crew orchestrates the handoff: the researcher pins the operative provisions, the drafter quotes the controlling language verbatim instead of paraphrasing from memory.

Create an API keyBook a demo

Which Legal Research MCP Server Should You Use

There are a few legal research MCP servers in the wild, and they cover different ground. Pick by what your agent actually needs to cite.

Harvey announced MCP support in December 2025, but it is gated to enterprise customers and ships no public developer SDK. The agentic-ops legal-mcp GitHub project is still a README with no working code as of June 2026, so treat it as a roadmap rather than a usable tool today.

If your agent needs verified US statutory text (USC, CFR, and all 50 state codes) in one place, the Vaquill AI statutes server is the path the walkthrough below covers.

Building a Legal Research Agent: Tool Chaining in Practice

Here's where MCP gets interesting. A single tool call is useful, but the real power comes from chaining tools together. An agent that can search and then pull the operative text is far more capable than one that guesses.

Consider this scenario. A user asks: "What standard does the APA set for a court reviewing an agency action?"

A naive agent would generate an answer from its training data and probably paraphrase the statute loosely. "Mostly right" isn't good enough for legal research, and a misquoted standard is worse.

Here's how an agent with the statutes MCP tools would handle it, step by step, with the actual tool calls and response fields the code needs to process.

Step 1: Find the operative provision.

The agent calls search_us_statutes for "scope of review agency action" and identifies the controlling APA provision, 5 U.S.C. 706. From here the agent knows exactly which section it needs to quote.

Step 2: Pull the full text.

The agent calls get_us_statute_section for "5 U.S.C. 706" and gets back the operative language verbatim, plus metadata, instead of a plausible reconstruction.

Step 3: Synthesize with full traceability.

The agent combines the result into a response that quotes the "arbitrary, capricious, an abuse of discretion" standard directly from 5 U.S.C. 706, with the section cited.

Every claim in that response traces back to an API call. The citation is real and the quoted text is the real text.

No hallucination. And importantly, every step is logged and auditable.

Every claim in that response traces back to an API call. No hallucination.

Agent Architecture Patterns for Legal Research

Once you have reliable legal data access, several agent architectures become practical. Here's how to think about each one from an implementation perspective.

Pattern 1: The Research Agent (Search-Verify-Synthesize)

This is the most common pattern. The agent receives a legal question, executes a multi-step workflow, and produces a sourced answer.

User Query
  → search_us_statutes (find the sections on point)
  → For each candidate section:
      → get_us_statute_section (pull the operative text)
  → Synthesize final answer with the quoted statutory text only

The key architectural decision is how broad to cast the initial search_us_statutes query. A narrow query returns the precise section fast; a broad one surfaces related provisions the agent may also need to quote.

The search tools give you deterministic, reproducible results, and get_us_statute_section guarantees the quoted language is the real text rather than a paraphrase.

Pattern 2: The Drafting Agent (Research-then-Write)

Write legal memos, briefs, or opinion letters with cited sources. The agent takes a topic or issue, researches the controlling statutory text using search_us_statutes and get_us_statute_section, then produces a structured document where every assertion maps to a specific source.

Topic/Issue
  → search_us_statutes (find the relevant sections)
  → For each section: get_us_statute_section (pin operative text)
  → Generate structured document with inline citations
  → For each statutory citation in document:
      → get_us_statute_section (final verification pass)

The verification pass at the end is critical. Even though the text came from a real database, the agent's reasoning about it could introduce errors. The final re-pull sweep catches any citations or quotes that got garbled during synthesis.

Pattern 3: The Due Diligence Agent (Extract-then-Verify)

Check every statutory citation in an existing document. Feed the agent a brief or memo, and it extracts each statute reference using regex or an LLM pass, then validates each one with get_us_statute_section.

This is the pattern that catches a misquoted or invented statute before it ships: every cite gets checked against the real section text before it goes out.

Input Document
  → Extract statutory citations (regex + LLM)
  → For each citation:
      → get_us_statute_section (does it exist? does the quote match?)
      → If the section is missing or the quote diverges:
          → flag for human review
  → Generate validation report

Run it against a memo citing 42 U.S.C. 1983, 5 U.S.C. 706, and 17 U.S.C. 107, and each one resolves to the real operative text.

Slip in a garbled or invented section and the lookup returns nothing, which is exactly the signal you want. A single misquote can change the reading of a provision.

Pattern 4: The Compliance Monitor (Periodic Search-and-Compare)

Monitor a set of statutory provisions and flag relevant changes. The agent runs periodic searches for specific provisions or legal concepts, compares the section text against a baseline, and alerts when the operative language changes.

Scheduled Trigger
  → For each monitored topic:
      → search_us_statutes (catch new or amended sections)
      → For each section: get_us_statute_section (pull current text)
      → Compare against stored baseline
      → If material change detected: alert
  → Update baseline

Pair search_us_statutes with get_us_statute_section to detect when a provision is amended or a new section is added. A statutory amendment that shifts a compliance obligation is exactly the kind of change this pattern is built to catch the day it lands.

Error Handling and Edge Cases

Building a reliable legal agent means handling the cases where tools don't return what you expect.

Section not found. get_us_statute_section may return no results for malformed or non-existent citations. Your agent should treat this as a signal to either retry with a partial match, or to tell the user the section couldn't be verified. Never silently drop an unresolvable citation.

Ambiguous results. A fuzzy concept query may return multiple matching sections. Your agent needs a disambiguation strategy: present options to the user, or use additional context (title, jurisdiction, subject) to narrow down.

Rate limits and credits. Heavy search workflows can consume significant credits. Use lightweight first passes and get_pricing to estimate costs. Design your agent to fail gracefully when credits are low.

Query breadth tradeoffs. A very broad search_us_statutes query can return a large result set. For most use cases, a focused query is enough. Start narrow and broaden only when the agent needs to enumerate related provisions.

Tips for Building Reliable Legal Agents

Building a legal agent that people can actually trust requires more care than a typical chatbot. A few patterns I've found essential:

Always ground claims in API results. Never let the agent fill in gaps from its training data when a tool call would give a definitive answer. If the agent can't find a section through the API, it should say so rather than guessing.

Verify every statutory citation against the section text. Before the agent includes any statute citation in its output, it should pull it through get_us_statute_section to confirm the section exists and the quoted language matches. This single step eliminates the most common failure mode of legal AI: invented or misquoted authority.

Quote the operative text, do not paraphrase. A citation to the right section is still misleading if the agent loosely restates the standard. Pull the verbatim language and quote it, so the reader sees the real provision rather than the model's reconstruction of it.

Log all API calls for audit trails. Legal work needs to be traceable. Every tool call your agent makes should be logged with the input, output, and timestamp. When a lawyer asks "where did this citation come from?", you should be able to point to the exact API response.

Design for human review. Even with grounded data, the agent's reasoning about that data can be wrong. Structure your agent's output so that a human can quickly verify each claim against its source. Include the citation, the relevant snippet, and a link to the full opinion.

Budget your tool calls. A naive agent might look up every single search result. In practice, you want to be selective: verify the top results, skip the clearly irrelevant ones, and run a lightweight first pass before committing to expensive full searches.

The Bigger Picture

Legal is one of the last professional domains where AI agents lack reliable, structured data access. Medical AI has PubMed and clinical databases. Financial AI has market data feeds and SEC filings.

Legal AI has been stuck with either general web scraping or expensive, proprietary platforms that don't expose APIs.

MCP changes the economics of this. The server can give any agent (Claude, GPT, Gemini, open-source models, custom builds) access to structured primary law: the U.S. Code, the CFR, the Federal Rules, and all 50 state codes, down to provisions like 42 U.S.C. 1983 and 5 U.S.C. 706.

The agent doesn't need to be trained on the law. It doesn't need a custom RAG pipeline. It doesn't need embeddings or vector stores. It just calls tools. (If you're weighing build options, see API call vs. RAG pipeline costs.)

The MCP ecosystem is growing fast. There are servers for GitHub, Slack, databases, file systems, and dozens of other data sources. Legal has been missing from this picture.

Legal data access should be as easy as any other integration: install a package, add a config, and the agent can pull real statutes through the public API (USC, CFR, 50-state codes) and quote the operative text verbatim (think 42 U.S.C. 1983, 17 U.S.C. 107, or 28 U.S.C. 1331).

As more agent frameworks adopt MCP (and most are converging on it), the agents that have access to specialized, high-quality data sources will be the ones that actually get used in professional settings.

General-purpose agents that hallucinate citations won't survive contact with real legal work. Agents that can search a real statutes database and quote the verified text will.

FAQ

What is a legal research MCP server?

A legal research MCP server is a program that exposes legal data tools (statute lookup, case search, citation resolution) over the Model Context Protocol, the open standard from Anthropic for connecting AI models to external data. Once registered, your agent can call those tools the same way it calls any other MCP tool, so it pulls real law instead of generating it from memory.

How do I add legal research to an AI agent?

Install a legal research MCP server, set its API key or OAuth credentials, and register it with your agent framework (LangGraph, CrewAI, the MCP client SDK, or an MCP-aware client like Claude Desktop). The agent's model then sees the legal tools in its tool list and calls them when a query needs real law. The walkthrough above shows the exact Python config.

Does an MCP server stop AI agents from hallucinating citations?

It removes the most common failure mode. When the agent pulls every statute section through a tool like get_us_statute_section and quotes the text verbatim, the answer is grounded in a real record. The Stanford study (Magesh et al., arXiv:2405.20362, 2024) found even purpose-built legal AI tools hallucinate 17 to 33 percent of the time without this kind of grounding, so the verification step matters.

Can I use a legal research MCP server with Claude, GPT, or open-source models?

Yes. MCP is model-agnostic. Any MCP-compatible agent or client (Claude, GPT through a client that speaks MCP, Gemini, or a custom build using the MCP client SDK) can call the same tools. The server does not care which model is on the other end.

What does the statutes API and MCP server cover?

The public statutes REST API and the MCP server cover USC, CFR, Federal Rules, 50-state codes, state constitutions, state court rules, and Executive Orders since 2015. That is a documented, versioned public surface. They do not return case law, opinions, or AI answers. Case-law research and grounded AI answers are features of the Vaquill AI product, used inside the app, not endpoints you build against.

How much does it cost to run a legal research agent?

It depends on call volume. New Vaquill AI accounts get 500 free credits on signup, enough to build and test. The get_pricing tool returns current credit pricing, and you can estimate cost before running expensive workflows.

For more on the MCP server and the public statutes API, see /features/legal-research or /legal-api.

Priyansh Khodiyar

Co-Founder & CTO

Priyansh leads engineering and AI at Vaquill, from the matter workbench to drafting, document comparison, document matrix, and citation-verified research.