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 the US Code, the CFR, and 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 can ground each legal claim in the text of a real section. The walkthrough below shows the config, a real tool run, and the architecture patterns that hold up.

Reviewed and corrected on 12 October 2026. This is general information, not legal advice.

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 that the three commercial legal research tools it tested (Lexis+ AI, Westlaw AI-Assisted Research and Ask Practical Law AI) each hallucinated between 17 and 33 percent of the time, which was less often than a general-purpose chatbot (GPT-4) but far from zero. Pulling the text of the cited section yourself, instead of trusting the model's memory of it, is the cheap check that catches an invented citation.

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. Run uvx vaquill-mcp with your API key set, and the agent gets statute search, section text, and citation-resolution tools that read real US law instead of guessing.
• What the MCP tools do: search (search_us_statutes), citation resolution (resolve_statute_citation), and full section text (get_us_statute_section_text), plus metadata, change history and watch tools. Search returns an actId; the text tool takes that actId, not a citation string.
• What it covers: US primary law: statutes, regulations, court rules, constitutions, the Federal Register, executive orders and agency guidance. It does not return case law or opinions.
• The payoff: the agent answers "what does 5 U.S.C. 706 say?" or "what is the fair use statute?" with the operative text of the section 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.

Scope note up front, because this is where developer posts confuse readers: the public REST API and the MCP server cover US primary law (statutes, regulations, court rules, constitutions, the Federal Register, executive orders, agency guidance, session laws). They do not return case law or opinions. This post is about wiring those tools into an agent.

This is for developers building agents programmatically. For an end-user guide on Claude Desktop or Cursor, see the Claude for US legal research tutorial.

The MCP tools

The server is generated from the live OpenAPI document, so the tool list tracks the API. The package's own README says to run the free get_pricing tool or inspect your client's tool list for the authoritative set. Four of them do most of the work in a research agent, and a fifth is free.

search_us_statutes

Hybrid semantic and keyword search across the US Code, the CFR, state codes, court rules and the other corpora. You pass a query in plain language and can narrow with corpusType, state, titleNumber, chapter, years and more. Each result carries a citation, a section title, an excerpt, an official source link and an actId.

Two things worth knowing. First, search ranks by meaning, so a topic query can land in a state code. On a test run, "fair use" ranked 17 U.S.C. 107 first, while "qualified immunity" returned state statutes (Iowa Code 670.4A and 669.14A) at the top, because that doctrine is judge-made and the federal statute people associate with it, 42 U.S.C. 1983, does not use the phrase. Scope with corpusType: "USC" or state: "federal" when you know you want federal law. Second, the actId is what every other tool takes. Do not build one by hand; the tool descriptions warn that hand-built ids usually 404.

resolve_statute_citation

Takes a Bluebook citation string such as 42 U.S.C. 1983 or 16 C.F.R. 444.1 and returns the exact section with its actId, an official link, and fields such as actStatus and currentThrough. It is the right call when the user hands you a citation instead of a question. On a test run, 5 U.S.C. 706 resolved to USC_T5_C7_S706 ("Scope of review"). An invented 42 U.S.C. 99999 came back resolved: false with missReason: "not_held". Treat resolved: false as unverified, never as current. A batch form, resolve_statute_citations_batch, handles a document's worth of citations in one call.

get_us_statute_section_text

Returns the text of a section by actId: plain text, HTML, or for US Code sections a content field that holds the operative text and a separate sourceCredit. This is the call that grounds a quote. On a test run, USC_T5_C7_S706 with format: "operative" returned the section beginning "To the extent necessary to decision and when presented, the reviewing court shall decide all relevant questions of law..." and listing, in paragraph (2)(A), the "arbitrary, capricious, an abuse of discretion, or otherwise not in accordance with law" standard.

get_us_statute_section

Despite the name, this returns metadata for a section by actId (citation, hierarchy, amendment history, links), not its text. It is useful for confirming you have the right section before you pay for the full body.

get_pricing

A free tool that needs no authentication. It returns per-endpoint credit costs, so an agent or a billing screen can estimate a workflow before it runs.

Installation

The MCP server is a Python package published on PyPI as vaquill-mcp. Run it with uvx, or install it:

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

It reads one environment variable:

export VAQUILL_API_KEY=vq_key_your_key_here

You need an API key to call the tools. The package README sends you to vaquill.ai to sign up, and the API page has the overview. The README also documents a hosted remote server for clients such as Claude.ai, Cursor and VS Code, which you configure with a URL and an Authorization: Bearer header instead of running anything locally.

Connecting from your agent code

The setup for Claude Desktop, Cursor, and VS Code is covered in the end-user tutorial. This section is about programmatic access from agent code.

Using the MCP client SDK

When you write the agent client yourself, connect with the MCP client SDK. Here is a minimal Python example that resolves a citation and then fetches its text. It has not been run against a live key in our October 2026 review, so check it against your key before relying on it.

import asyncio
import json

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 def main():
    async with stdio_client(server_params) as (read, write):
        async with ClientSession(read, write) as session:
            await session.initialize()

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

            # 1. Resolve a citation to a section
            resolved = await session.call_tool(
                "resolve_statute_citation", arguments={"cite": "5 U.S.C. 706"}
            )
            data = json.loads(resolved.content[0].text)
            if not data["resolved"]:
                raise SystemExit("Citation did not resolve: treat it as unverified")
            act_id = data["section"]["actId"]  # "USC_T5_C7_S706"

            # 2. Fetch the text of that section
            text = await session.call_tool(
                "get_us_statute_section_text",
                arguments={"act_id": act_id, "format": "operative"},
            )
            print(text.content[0].text)


asyncio.run(main())

This is the shape you would use inside an agent framework such as 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

In LangGraph, each MCP tool can become a node in your graph, and you define edges for the research workflow you want. For example:

search_node → resolve_node → section_text_node → synthesize_node

MCP tools hold no conversation state on your side. Your agent graph tracks which sections have been found and which text has been pulled, and each tool call takes inputs and returns structured data.

Integrating with CrewAI

CrewAI agents can use MCP tools as agent tools. Define a "Statute Researcher" agent with access to search_us_statutes, resolve_statute_citation and get_us_statute_section_text, and a "Drafting" agent that consumes the pinned text. The researcher pins the operative provisions; the drafter quotes the controlling language verbatim instead of paraphrasing from memory.

Which legal research MCP server should you use

A few legal MCP servers exist, and they cover different ground. Pick by what your agent needs to cite and where you want it to run.

Harvey announced its MCP approach on 22 December 2025, and its developer guide at developers.harvey.ai describes the hosted server and its tools such as ask_harvey and ask_about_vault. The legal-mcp README says its validate_citation tool checks structure and reporter format and "does not establish existence or good-law status", which is a useful distinction to carry into your own agent: format-valid and real are different checks.

Building a legal research agent: tool chaining in practice

A single tool call is useful, but the real power comes from chaining tools. An agent that can search or resolve 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 generates an answer from its training data and paraphrases the statute loosely. "Mostly right" is not good enough for legal research.

Here is how an agent with the MCP tools handles it:

Step 1: Find the operative provision. The agent calls search_us_statutes for "scope of review agency action arbitrary capricious" with corpusType: "USC". On a test run the first result was USC_T5_C7_S706, 5 U.S.C. 706, "Scope of review".

Step 2: Pull the full text. The agent calls get_us_statute_section_text with that actId and gets the text of the section as published, instead of a reconstruction.

Step 3: Synthesize with traceability. The agent answers with the "arbitrary, capricious, an abuse of discretion, or otherwise not in accordance with law" language quoted from 5 U.S.C. 706(2)(A), and cites the section.

Every claim in that response traces back to a tool call, and each call can be logged and audited.

Agent architecture patterns for legal research

Once you have reliable access to the text of the law, several agent architectures become practical.

Pattern 1: The research agent (search, verify, synthesize)

The most common pattern. The agent receives a legal question, runs 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_text (pull the operative text)
  → Synthesize final answer quoting the statutory text only

The key decision is how broad to make the first search_us_statutes query. A narrow, scoped query returns the precise section fast; a broad one surfaces related provisions the agent may also need to quote. Search results come from a ranking, so for reproducibility log the query, filters and returned actIds.

Pattern 2: The drafting agent (research, then write)

Write memos or opinion letters with cited sources. The agent takes an issue, researches the controlling text with search and the text tool, 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_text (pin operative text)
  → Generate structured document with inline citations
  → resolve_statute_citations_batch (final check of every cite in the draft)

The final verification pass matters. Even when the text came from a real source, the agent's reasoning about it can introduce errors, and a re-resolve of every citation in the draft catches a garbled one.

Pattern 3: The due diligence agent (extract, then verify)

Check every statutory citation in an existing document. Feed the agent a brief or memo, extract each statute reference with a regex or an LLM pass (the REST API also has an extract-citations endpoint that finds and resolves non-case citations in a block of text), then resolve each one.

Input Document
  → Extract statutory citations
  → resolve_statute_citations_batch (does each one exist?)
  → For each resolved cite: get_us_statute_section_text (does the quote match?)
  → If a cite is unresolved or the quote diverges: flag for human review
  → Generate validation report

A memo citing 42 U.S.C. 1983, 5 U.S.C. 706 and 17 U.S.C. 107 should resolve all three. An invented section comes back resolved: false, which is the signal you want. Note that this checks that the section exists and what it says. Whether the memo's argument is right is still a human call.

Pattern 4: The compliance monitor (watch, then compare)

Monitor a set of provisions and flag relevant changes. You can poll and diff section text yourself, or subscribe to a board with the watch tools (list_boards, create_watch, list_watch_changes), which notify you by webhook or email when a source refreshes with real changes.

Scheduled Trigger
  → For each monitored section: get_us_statute_section_text
  → Compare against stored baseline
  → If the text changed: queue for human review
  → Update baseline

A text diff tells you that something changed, not why, and a change in our observation record is not the same as an effective date. Read the amendment history and the official source before telling a client that an obligation changed.

Error handling and edge cases

Unresolved citation. resolve_statute_citation returns resolved: false with a missReason for a citation it cannot verify. Tell the user the citation could not be verified. Never silently drop it and never substitute a near match.

Ambiguous results. A fuzzy concept query can return sections from several jurisdictions. Pass corpusType and state to narrow, or show the user the options.

Credits and rate limits. Every call has a credit cost, and get_pricing lists them. Limits are enforced per API key, and a 429 response carries a Retry-After header. Design the agent to back off instead of retrying in a tight loop.

Query breadth. A broad query can return a large result set. Start with a focused, scoped query and widen only when you need to enumerate related provisions.

Tips for building reliable legal agents

Ground claims in tool results. Never let the agent fill a gap from training data when a tool call would give a definitive answer. If it cannot find the section, it should say so.

Verify every statutory citation. Before the agent includes a citation in its output, resolve it and compare the quoted language with the section text. This one step removes 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.

Log every call. Record the input, output and timestamp of each tool call. When a lawyer asks "where did this come from?", you can point at the exact response.

Design for human review. Even with grounded data, the agent's reasoning can be wrong. Show the citation, the relevant snippet and a link to the official source so a human can check each claim.

Budget your tool calls. Verify the top results, skip the clearly irrelevant ones, and run a cheap first pass before an expensive one.

The bigger picture

Medical AI has PubMed and clinical databases. Financial AI has market data feeds and SEC filings. For legal work, agents have too often been stuck with web scraping or proprietary platforms. An MCP server gives any MCP-capable agent (Claude, GPT through a client that speaks MCP, Gemini, open-source models, custom builds) structured access to primary law, down to provisions like 42 U.S.C. 1983, 5 U.S.C. 706 and 17 U.S.C. 107, so the agent does not rely on what it memorized in training. (If you are weighing build options, see API call vs. RAG pipeline costs.)

FAQ

What is a legal research MCP server?

A legal research MCP server is a program that exposes legal data tools (statute lookup, citation resolution, search) over the Model Context Protocol, the open standard Anthropic introduced for connecting AI models to external data. Once registered, your agent can call those tools like any other MCP tool, so it reads the 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 such as Claude Desktop). The model then sees the legal tools in its tool list and calls them when a query needs real law. The Python example above shows the client side.

Does an MCP server stop AI agents from hallucinating citations?

It removes a common failure mode. When the agent resolves each citation and quotes the section text from a tool, the quoted language comes from a real record. The Stanford study (Magesh et al., arXiv:2405.20362) found that the three commercial legal research tools it tested each hallucinated between 17 and 33 percent of the time, so a verification step is worth adding. A tool does not make the agent's reasoning about the text correct, so keep a human review step.

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 can call the same tools, and the server does not care which model is on the other end.

What does the Vaquill statutes API and MCP server cover?

US primary law: the US Code, the CFR, state statutes and regulations, constitutions, court rules, the Federal Register, executive orders and federal agency guidance, plus session laws. It does not return case law or opinions. The live coverage endpoint, GET /api/v1/us/statutes/coverage, is the authoritative list for any jurisdiction.

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

Each call has a credit cost, so it depends on call volume. The free get_pricing tool returns the per-endpoint credit costs, which lets you estimate a workflow before you run it.

For the US statutes, regulations and court rules these tools read, see the US primary law API.

Priyansh Khodiyar

Co-Founder & CTO

Priyansh leads engineering and AI at Vaquill AI: the pipelines that pull statutes, regulations and court rules from every US jurisdiction's official publisher, and the REST API, MCP server and open dataset that serve them.