How do I use Legal Court MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Legal Court MCP Server Search for free speech cases in the Supreme Court." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Legal Court MCP Server

by AiAgentKarl

Overview Schema Source Related Servers Score Discussions Admin

Python

Remote

Legal Court MCP Server

MCP Server for court decisions, case law, and legal research. Gives AI agents access to 3M+ US court decisions via CourtListener and EU legislation via EUR-Lex.

Tools

Tool	Description
`search_cases`	Search 3M+ US court decisions by keyword
`get_case_details`	Get full case details (judges, citations, opinion text)
`search_by_citation`	Find a case by legal citation (e.g. "410 U.S. 113")
`get_court_info`	Information about a specific court
`search_judges`	Search judges by name
`search_eu_law`	Search EU legislation and case law via EUR-Lex

Related MCP server: legal-mcp

Installation

pip install legal-court-mcp-server

Usage with Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "legal-court": {
      "command": "legal-court-server"
    }
  }
}

Or with uvx (no install needed):

{
  "mcpServers": {
    "legal-court": {
      "command": "uvx",
      "args": ["legal-court-mcp-server"]
    }
  }
}

Data Sources

CourtListener — Free, open database of 3M+ US court opinions. No API key needed.
EUR-Lex — Official EU law database with regulations, directives, and case law.

Examples

search_cases("free speech first amendment")
search_cases("copyright fair use", court="scotus")
search_by_citation("347 U.S. 483")  # Brown v. Board of Education
get_court_info("scotus")
search_judges("Ruth Bader Ginsburg")
search_eu_law("artificial intelligence regulation")

More MCP Servers by AiAgentKarl

Category	Servers
🔗 Blockchain	Solana
🌍 Data	Weather · Germany · Agriculture · Space · Aviation · EU Companies
🔒 Security	Cybersecurity · Policy Gateway · Audit Trail
🤖 Agent Infra	Memory · Directory · Hub · Reputation
🔬 Research	Academic · LLM Benchmark · Legal

→ Full catalog (40+ servers)

License

MIT

Available Tools

6 tools

get_case_detailsA

Holt vollständige Details eines Falls von CourtListener.

Args: case_id: Die Cluster-ID oder Opinion-ID des Falls. Erhält man aus search_cases (cluster_id oder id Feld).

Returns: Vollständige Falldetails: Name, Richter, Zitierungen, Präzedenzstatus und Textausschnitt der Entscheidung.

Beispiele: get_case_details('2812209') # Cluster-ID

ParametersJSON Schema

Name	Required	Description	Default
`case_id`	Yes

TDQS

A3.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description lacks any behavioral traits such as rate limits, authentication needs, or potential side effects. It only describes the return content, not how the tool behaves during operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively concise with clear sections and an example. The first sentence states the purpose directly, though it could be slightly shorter without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple retrieval tool with one parameter and no output schema, the description is adequate but incomplete. It lists return fields vaguely but does not mention error handling or API specifics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The parameter case_id is simply a string in the schema, but the description adds critical context: it can be a cluster or opinion ID and is obtained from search_cases. This compensates for the 0% schema description coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Holt vollständige Details eines Falls von CourtListener', indicating a specific verb (holt), resource (Falldetails), and source (CourtListener). The example differentiates from sibling search tools by requiring a known ID.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains that the case_id comes from search_cases, implying usage after searching. However, it does not explicitly state when not to use this tool or compare it to alternatives like search_by_citation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_court_infoA

Holt Informationen über ein bestimmtes Gericht.

Args: court_id: Die Court-ID, z.B.: 'scotus' — US Supreme Court 'ca1' bis 'ca11' — US Circuit Courts 'cafc' — Federal Circuit 'cadc' — DC Circuit 'dcd' — DC District Court 'nyed', 'nysd' — NY District Courts

Returns: Gerichtsname, Jurisdiktion, Gründungsdatum und Status.

Beispiele: get_court_info('scotus') get_court_info('ca9')

ParametersJSON Schema

Name	Required	Description	Default
`court_id`	Yes

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided. The description discloses return values but does not mention behavioral traits such as authentication requirements, rate limits, error handling for invalid court IDs, or potential side effects. It adequately describes what the tool does but lacks deeper transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with an Args/Returns section and examples. It is front-loaded with the main purpose. While it could be slightly more concise by moving the bullet list into the schema, it is efficient and not overly verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description is complete. It covers the parameter format, return values, and provides usage examples. No further context is needed for an agent to select and invoke this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero coverage for the 'court_id' parameter. The description compensates excellently by listing valid values and formats (e.g., 'scotus', 'ca1'-'ca11', 'cafc') and providing examples. This adds significant meaning beyond the schema's bare definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: retrieving information about a specific court. It specifies the verb ('Holt Informationen') and resource ('Gericht'), and provides detailed examples of court IDs (e.g., 'scotus', 'ca1'-'ca11') and return fields (name, jurisdiction, founding date, status). The sibling tools (e.g., get_case_details, search_cases) are distinct in purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives examples of how to use the tool but does not explicitly state when to use it versus alternatives. It implies usage through examples, but there is no guidance on when not to use it or which sibling tool to choose instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_by_citationA

Findet einen Fall anhand seiner juristischen Zitierung.

Args: citation: Die Zitierung, z.B. '410 U.S. 113' (Roe v. Wade), '347 U.S. 483' (Brown v. Board of Education), '384 U.S. 436' (Miranda v. Arizona)

Returns: Passende Fälle mit vollständigen Metadaten.

Beispiele: search_by_citation('410 U.S. 113') search_by_citation('554 U.S. 570')

ParametersJSON Schema

Name	Required	Description	Default
`citation`	Yes

TDQS

A4.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states it returns matching cases with metadata but does not disclose aspects like multiple results, error handling, or authentication needs. Basic transparency but limited.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, structured with Args, Returns, and Beispiele sections. Every sentence adds value without repetition or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema or annotations, the description covers purpose, parameter format, return type, and examples. It is complete enough for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no description for the citation parameter (0% coverage). The description compensates by providing a detailed explanation with examples of valid citations (e.g., '410 U.S. 113'). This adds significant meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Findet einen Fall anhand seiner juristischen Zitierung' which is a specific verb+resource combination. It distinguishes from sibling tools like search_cases (general search) and get_case_details (case ID based).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides examples of when to use the tool (e.g., '410 U.S. 113') and implies the input format. However, it does not explicitly state when not to use it or compare with alternatives like get_case_details.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_casesA

Durchsucht 3M+ US-Gerichtsentscheidungen nach Stichwörtern.

Args: query: Suchbegriff(e), z.B. 'free speech first amendment' court: Optional — Gericht filtern, z.B. 'scotus' (Supreme Court), 'ca1' bis 'ca11' (Circuit Courts), 'dcd' (DC District) limit: Maximale Anzahl Ergebnisse (Standard: 10, Max: 20)

Returns: Gefundene Fälle mit Name, Gericht, Datum, Zitierung und Textausschnitt.

Beispiele: search_cases('copyright fair use') search_cases('miranda rights', court='scotus') search_cases('data privacy GDPR', limit=5)

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`court`	No
`limit`	No

TDQS

A4.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It mentions no side effects, authentication requirements, rate limits, or behavior beyond searching. Since it's a search tool, it's likely read-only, but the description does not confirm this.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with clear sections (Args, Returns, Examples). It is front-loaded with the main purpose, and every sentence adds value. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 3 parameters, no output schema, and no annotations, the description covers the return format (cases with name, court, date, citation, excerpt). Lacks details on pagination or ordering, but is mostly complete for a search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, yet the description fully explains each parameter: query as search terms, court as optional filter with examples (scotus, ca1-11, dcd), and limit with default (10) and max (20). This adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches over 3 million US court decisions by keywords, using the specific verb 'Durchsucht' and resource 'US-Gerichtsentscheidungen'. It distinguishes itself from siblings like search_eu_law (EU law) and search_by_citation (citation search).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Examples show typical usage patterns, and the court parameter list provides guidance for filtering. However, it lacks explicit statements about when to use this tool vs. alternatives (e.g., when to use search_by_citation) or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_eu_lawA

Durchsucht EU-Recht und Rechtsprechung über EUR-Lex.

Args: query: Suchbegriff(e) auf Englisch, z.B. 'data protection', 'consumer rights', 'competition law' limit: Maximale Anzahl Ergebnisse (Standard: 10, Max: 20)

Returns: EU-Rechtsakte und Urteile mit Titel, CELEX-Nummer und Datum.

Beispiele: search_eu_law('artificial intelligence regulation') search_eu_law('GDPR data protection', limit=5)

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`limit`	No

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must fully disclose behavioral traits. It only mentions the read nature implicitly (search) but does not state that it is non-destructive, nor does it mention auth requirements, rate limits, or side effects. The description is insufficient for a tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-organized, with clear sections (Args, Returns, Examples). Every sentence adds value, and the structure is front-loaded with the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has only 2 parameters, no output schema, and no nested objects, the description adequately covers what is needed: search inputs, return format (title, CELEX number, date), and examples. No critical gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, but the description compensates by explaining the 'query' parameter with examples and the 'limit' parameter with default and max values. This adds meaningful context beyond the schema types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches EU law and case law via EUR-Lex, using a specific verb and resource. However, it does not explicitly differentiate from sibling tools like search_cases or search_by_citation, which may have overlapping scopes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes usage tips such as using English search terms and default limit values, and provides examples. However, it lacks guidance on when to use this tool versus alternatives, and does not specify exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_judgesA

Sucht Richter nach Name und zeigt deren Informationen.

Args: name: Name des Richters, z.B. 'Ruth Bader Ginsburg', 'John Roberts', 'Sonia Sotomayor'

Returns: Richter-Informationen: Name, Gericht, Ernennung, politische Zugehörigkeit.

Beispiele: search_judges('Ketanji Brown Jackson') search_judges('Clarence Thomas')

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It specifies returned fields (name, court, appointment, political affiliation) but does not disclose potential issues like no matches found, multiple matches, or required permissions. Adequate but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured with clear sections (Args, Returns, Beispiele). The first sentence immediately conveys purpose. No unnecessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description covers purpose, parameter usage, and return fields. It lacks details on edge cases (e.g., partial name matching, error handling) but is sufficient for basic use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage for the single parameter 'name'. The description compensates by explaining the parameter meaning ('Name des Richters') and providing concrete examples (e.g., 'Ruth Bader Ginsburg'), adding significant value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Sucht Richter nach Name und zeigt deren Informationen' (Search for judges by name and shows their information), providing a specific verb and resource. It differentiates from sibling tools like search_cases, search_by_citation, and search_eu_law, which handle different entities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for searching judges by name, but provides no explicit guidance on when to use versus alternatives. Sibling tools are listed in context but not compared, limiting guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.1.0May 26, 2026
- First observedget_case_details
- First observedget_court_info
- First observedsearch_by_citation
- First observedsearch_cases
- First observedsearch_eu_law
- First observedsearch_judges

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool targets a distinct legal research need: case details, court info, citation search, keyword search, EU law, and judge info. No overlaps.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with underscores (search_cases, get_case_details, etc.). No naming variations.

Tool Count5/5

6 tools cover the core needs of legal research (search, citation, details, court info, judges, EU law) without redundancy. Well-scoped.

Completeness4/5

Covers major functionalities for US and EU law research. Missing advanced features like docket access or filtering by date, but core workflows are present.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Lawstronaut A
com.lawstronaut
Connect AI to millions of laws and court cases with the Lawstronaut MCP.
Legal & Compliance Research & Data Web Scraping
1631
CourtListener B
io.github.Vaquill-AI
MCP for CourtListener: US federal and state opinions, dockets, judges, plus eCFR regulations.
Legal & Compliance Government Data
3422
Pangolinfo Amazon Data MCP
io.github.Pangolin-spg
Real-time Amazon, WIPO & PACER data for AI agents — 19 tools via the MCP protocol.
E-commerce & Retail Search Research & Data
21
ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24

Related MCP Servers

courtlistener-mcp
Legal & Compliance Search RAG Systems
DefendTheDisabled
A
license
Not graded
quality
C
maintenance
An MCP server providing AI agents access to CourtListener's comprehensive legal database, featuring semantic search, hybrid search, citation verification, and research tools.
Updated 6 months ago (2026-03-07 19:01 UTC)
7
MIT
legal-mcp
Legal & Compliance Search
MCPServings
A
license
Not graded
quality
D
maintenance
A remotely callable MCP server for US legal research that provides tools to search, retrieve, and analyze US case law from the CourtListener API, enabling agents to build evidence packs from primary sources without generating legal content.
Updated 3 months ago (2026-06-17 03:13 UTC)
MIT
mcp-courtwatch
Legal & Compliance Government Data
haksanlulz
A
license
A
quality
A
maintenance
MCP server for free U.S. case-law and court-docket search via CourtListener, providing tools for opinion search, docket lookup, citation verification, and more.
Updated 5 days ago (2026-09-03 13:13 UTC)
10
101
1
MIT
courtlistener-mcp
Legal & Compliance Government Data Open Data
Vaquill-AI
A
license
A
quality
D
maintenance
An MCP server that provides AI assistants access to the CourtListener legal database (US court opinions, dockets, RECAP, PACER, oral arguments, judges) and the full eCFR federal regulations via the official CourtListener API v4. It supports bring-your-own-key authentication and is designed for use with MCP-compatible clients like Claude, VS Code, and Cursor.
Updated 2 days ago (2026-09-06 17:37 UTC)
34
2
MIT

Appeared in Searches

MCP servers about European Union and Hong Kong law

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AiAgentKarl/legal-court-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server