This MCP server provides read-only access to US legal data across five authoritative sources, enabling legal research with verifiable, officially-cited results.
Federal Legislation: Search and retrieve federal bills by congress session (e.g., 118th) and bill type (HR, S, HRes, etc.), and fetch full details including latest action/status.
Enacted Law Packages (GovInfo): List and retrieve published legal packages from the US Code (USCODE), CFR, Federal Register (FR), and Statutes at Large (STATUTE), including PDF/XML/TXT download links, with optional filtering by modification date.
Federal Register: Full-text search over 1M+ FR documents (1994–present), with filters for document type (rules, proposed rules, notices) and presidential documents (executive orders, proclamations). Fetch individual documents with full metadata and official citations (e.g., 91 FR 41591). No API key required.
Case Law: Full-text search over 8M+ court opinions via CourtListener — especially valuable for state courts (e.g., California, New York) but also covers federal courts. Retrieve specific opinion clusters by ID with human-readable citations (e.g., People v. Miranda-Guerrero, 519 P.3d 1004). No API key required.
Current Code of Federal Regulations (eCFR): Full-text search over 412,846 sections of the live, up-to-date CFR, and retrieve point-in-time amendment history for specific sections (e.g., 15 CFR § 744.3). No API key required.
Every result includes a lex_uri (resolvable API URL), human_readable_citation (official legal citation), and source_url (public page).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@us-eli-mcp search for bills about healthcare in the 118th Congress"
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.
MCP server for US law with verifiable citations. Five sources behind ten read-only tools:
Congress.gov API - the federal legislative process: bills as they move through committees and floor votes.
GovInfo API - enacted law text as published packages: US Code, Statutes at Large, CFR annual editions, Federal Register issues.
Federal Register API - full-text search over 1,003,504 FR documents (1994-2026, live-verified 2026-07-07), including 8,513 presidential documents (1,550 executive orders). Keyless.
CourtListener search API - full-text search over 8,294,123 court opinions (live-verified 2026-07-07). The headline value is STATE case law (California, New York, Texas, ...), which no federal source covers. Keyless, ~5 requests/min anonymous.
eCFR API - the CURRENT Code of Federal Regulations: section-level full-text search over 412,846 sections plus per-section amendment history. Keyless.
State legislation (all 50 states) - see LegiScan, a free-tier aggregator (30,000 queries/month) not wrapped here.
A federal case-law workhorse - for heavy federal case-law research the mature MIT-licensed wrappers (blakeox/courtlistener-mcp, john-walkoe/courtlistener_citations_mcp) remain the recommendation; the case-law tools here exist primarily for state courts. See SOURCES.md.
Related MCP server: CongressMCP-full
Tool | Purpose |
| List bills by congress (e.g. |
| Full detail + latest action for one bill |
| List GovInfo packages in a collection ( |
| Metadata + download links (PDF/XML/TXT) for one package |
| Full-text search over FR documents; filter rules, notices, executive orders |
| One FR document with its official citation (e.g. |
| Full-text search over 8M+ opinions; |
| One opinion cluster by |
| Full-text search over the current CFR (eCFR) |
| Amendment history of one CFR section (e.g. 15 CFR 744.3) |
| Declare what this connector covers, when each family was captured, and - explicitly - what it does NOT cover. Every gap carries a fallback. |
Every response carries lex_uri (a resolvable API URL), human_readable_citation
(the official convention: "H.R. 1, 118th Congress", "91 FR 41591",
"People v. Miranda-Guerrero, 519 P.3d 1004 (California Supreme Court 2022)",
"15 CFR § 744.3") and source_url (the public page). Reporter citations are
taken verbatim from the source and never fabricated; when none exists the
docket number is used instead.
pip install us-eli-mcpSmart App Control blocks unsigned executables, which covers uvx.exe, pip.exe
and the us-eli-mcp.exe launcher that pip writes at install time. The python.exe and
py.exe from the python.org installer are signed by the Python Software
Foundation, so running the module through the interpreter works:
python -m pip install us-eli-mcp
python -m us_eli_mcppip.exe is blocked for the same reason, so install with python -m pip, not
pip install. If python is not on PATH, use the Windows launcher: py -3 -m us_eli_mcp.
{ "mcpServers": { "us-eli-mcp": { "command": "python", "args": ["-m", "us_eli_mcp"] } } }Do not turn Smart App Control off to work around this - it cannot be re-enabled without reinstalling Windows.
Env var | Default |
|
|
| reuses |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The Federal Register, CourtListener and eCFR tools need no key at all.
Apache-2.0 (code). Congress.gov, GovInfo, Federal Register and eCFR data are US government works (public domain). CourtListener data is provided by the Free Law Project.
Declare what this connector covers, how it is sourced, and what it does NOT cover.
Call this before telling a user that the law "does not contain" something, and whenever a search comes back empty: the absence may be a gap in this connector rather than in the law. Every gap carries a fallback saying where to look instead.
Returns:
Coverage with families, an as-of note, and a non-empty list of known gaps.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| status | No | |
| families | No | |
| as_of_note | Yes | States what the dates mean, and what they do not promise. |
| known_gaps | No | Never empty. An empty list would mean 'not checked', not 'no gaps'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds valuable context by explaining the 'open world' nuance and detailing the return structure (families, as-of note, non-empty list of gaps). It also reveals each gap carries a fallback, which is behavioral insight beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and economical. The first line states the core purpose, the following lines give precise invocation triggers, and the Returns clause summarizes the output structure. Every sentence earns its place without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with full annotation coverage and an output schema, the description is complete. It explains the why, when, and what to expect, and even includes the critical gap/fallback behavior. Nothing essential is missing for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so by the established baseline, the description deserves a 4. Since there are no parameters to document, the description appropriately focuses on return semantics and usage context without unnecessary parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Declare') and clearly defines the resource: what this connector covers, how it is sourced, and what it does NOT cover. It distinctly positions this tool against the sibling search/get tools by focusing on coverage and gaps, leaving no ambiguity about its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call the tool: before telling a user the law 'does not contain' something, and whenever a search comes back empty. It explains the reasoning (absence may be a connector gap rather than a legal gap) and provides a crucial fallback instruction. This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full detail (including latest action/status) for one bill.
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | bill number, e.g. ``1``. | |
| congress | Yes | e.g. ``118``. | |
| bill_type | Yes | e.g. ``"hr"``. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds the specific detail that the tool returns 'latest action/status', providing valuable behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information, no wasted words. Perfectly concise for this simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present and annotations covering safety, the description sufficiently explains purpose and contents (full detail including latest action/status). Complete for a fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 3 parameters with clear descriptions, covering 100% of parameters. The tool description adds no additional parameter information beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Fetch' targeting 'full detail' for a single bill, including the latest action/status. This clearly distinguishes it from sibling search tools like us_search_bills.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need complete details for a known bill (required congress, bill_type, number). It doesn't explicitly exclude alternatives, but the context with sibling tools provides implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one opinion cluster by its CourtListener cluster_id.
Uses the keyless search endpoint with a cluster_id:{id} field query
(the authenticated /clusters/{id}/ endpoint is deliberately not used).
| Name | Required | Description | Default |
|---|---|---|---|
| cluster_id | Yes | e.g. ``8512159`` - take it from `us_search_case_law`. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly, idempotent, and non-destructive hints. The description adds that the tool uses a keyless search endpoint and avoids the authenticated endpoint, which is useful context but not critical behavioral disclosure beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no unnecessary words. Each sentence conveys essential information: purpose and implementation detail. Efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with annotations and an output schema, the description is mostly complete. It could mention response format or error conditions, but the existence of output schema mitigates this. The guidance on parameter sourcing adds value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the parameter with example and source. The description reaffirms that cluster_id is the identifier, but does not add new semantic details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches one opinion cluster by its CourtListener cluster_id, using a specific verb and resource, and distinguishes it from siblings like us_search_case_law by specifying it is a fetch operation based on an ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the parameter source (from us_search_case_law) and notes the deliberate choice of keyless endpoint over authenticated, but does not explicitly state when to use or not use this tool versus alternatives beyond the endpoint choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the amendment history (point-in-time versions) of one CFR section.
| Name | Required | Description | Default |
|---|---|---|---|
| part | Yes | part identifier, e.g. ``"744"``. | |
| title | Yes | CFR title number, e.g. ``15``. | |
| section | Yes | section identifier, e.g. ``"744.3"`` - take title/part/section from `us_search_cfr_sections`. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, signaling a safe, read-only operation. The description adds 'point-in-time versions' but does not disclose additional behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information: 'Fetch the amendment history (point-in-time versions) of one CFR section.' No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and the annotations cover safety and idempotency, the description is complete for its simplicity. It clarifies the result is version history, which is essential for understanding the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all three parameters. The description adds a hint about sourcing values from us_search_cfr_sections but does not add semantic meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches amendment history of a specific CFR section, using a specific verb ('Fetch') and resource ('amendment history of one CFR section'). This distinguishes it from sibling tools like us_search_cfr_sections, which search for sections, and others that retrieve different document types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It mentions taking parameters from us_search_cfr_sections, but does not specify scenarios where this tool is preferred or excluded, such as when full text vs history is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch metadata and content-format download links for one GovInfo package.
| Name | Required | Description | Default |
|---|---|---|---|
| package_id | Yes | a GovInfo package id, e.g. ``"USCODE-2023-title50"`` or a Federal Register document id - take these from `us_list_code_packages`. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it fetches metadata and download links, which is consistent and provides minimal extra context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence of 10 words, efficient and front-loaded with key action and object. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (so return values are documented elsewhere), the description is adequate for a single-parameter fetch tool. However, more context about what exactly constitutes 'content-format download links' could be helpful but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%. The description does not add additional meaning beyond what the schema's `description` field already provides for `package_id`.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch', the resource 'metadata and content-format download links', and scope 'for one GovInfo package'. It distinguishes from sibling tools like `us_list_code_packages` which lists packages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are stated in the description. However, the parameter description for `package_id` implies usage by referencing `us_list_code_packages` as source, providing indirect guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full metadata for one Federal Register document.
| Name | Required | Description | Default |
|---|---|---|---|
| document_number | Yes | an FR document number, e.g. ``"2026-13726"`` - take it from `us_search_federal_register`. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds no extra behavioral context beyond what annotations provide, such as rate limits or return format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and resource, containing no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 an output schema, the description is adequate. It could mention the type of metadata returned, but that is likely covered by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the parameter. The description does not add additional parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch full metadata for one Federal Register document' uses a specific verb ('Fetch') and resource ('full metadata for one Federal Register document'), clearly distinguishing this tool from siblings like search and list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating it fetches one document, and the parameter description hints at prior use of us_search_federal_register. However, no explicit when-to-use or when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List enacted-law packages in a GovInfo collection modified since a given date.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | max results (default 20). | |
| collection | Yes | a GovInfo collection code, e.g. ``"USCODE"`` (United States Code), ``"CFR"`` (Code of Federal Regulations), ``"FR"`` (Federal Register), ``"STATUTE"`` (Statutes at Large). | |
| start_date | No | ISO 8601 UTC timestamp (e.g. ``"2023-01-01T00:00:00Z"``); only packages modified on/after this date are returned. | 1900-01-01T00:00:00Z |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds the date-filtering behavior but does not disclose additional behavioral traits such as pagination or the handling of large result sets. It is adequate but not enhanced beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, highly concise with no extraneous information. Every word serves a purpose, and it front-loads the core action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 3 parameters, a clear output schema, and rich annotations, the description covers the essential purpose and filter. It does not elaborate on the meaning of 'enacted-law packages' or the exact behavior of the date filter, but the schema and annotations fill gaps. Overall complete and appropriate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters and their types. The description does not add any extra meaning beyond what the schema provides, meeting but not exceeding the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb ('List'), the resource ('enacted-law packages in a GovInfo collection'), and the filter ('modified since a given date'). It effectively distinguishes from sibling tools like us_get_code_package (single package) and search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing packages modified after a date, but provides no explicit guidance on when to choose this tool over alternatives like us_get_code_package or search tools. No exclusion criteria or context about scope is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List US federal bills of a given congress and bill type.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | max results (default 20, API caps around 250). | |
| congress | Yes | e.g. ``118`` (2023-2024 session). | |
| bill_type | Yes | one of ``"hr"``, ``"s"``, ``"hres"``, ``"sres"``, ``"hjres"``, ``"sjres"``, ``"hconres"``, ``"sconres"``. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description does not add behavioral context such as pagination behavior or rate limits, leaving the agent reliant on annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it is slightly too brief, missing context that could fit without increasing length significantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and comprehensive annotations, the description is minimally adequate. It does not explain return format or usage context beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed parameter descriptions. The tool description adds no additional semantic meaning beyond restating the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'US federal bills', with key filtering parameters 'congress' and 'bill type'. It effectively distinguishes from sibling tools like 'us_get_bill' which retrieves a single bill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'us_search_case_law' or 'us_get_bill'. The usage context is implied but not detailed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search over 8M+ US court opinions (CourtListener, keyless).
The headline value is STATE case law - no other tool in this server covers state courts. Federal courts are searchable too, but dedicated CourtListener MCP wrappers exist for heavy federal case-law work.
| Name | Required | Description | Default |
|---|---|---|---|
| court | No | optional CourtListener court id to scope the search, e.g. ``"cal"`` (California Supreme Court), ``"ny"`` (NY Court of Appeals), ``"texapp"`` (Texas Court of Appeals), ``"scotus"``. | |
| limit | No | max results (default 20; the API returns 20 per page). | |
| query | Yes | full-text query, e.g. ``"negligence standard of care"``. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds key context: the tool is keyless (no API key required) and sources from CourtListener, which is beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short paragraphs with the core purpose in the first sentence. Every sentence adds value without redundancy. Structure is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but indicated), the description need not cover return values. It adequately covers source, scope, and alternative usage. The parameter schema is rich, and the description complements it with high-level guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add further meaning to the parameters beyond what the input schema already provides (e.g., examples for court, limit, query).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs full-text search over 8M+ US court opinions using CourtListener. It explicitly highlights that the headline value is state case law, which distinguishes it from sibling tools covering federal courts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides direct guidance: use primarily for state case law, and notes that federal courts are also searchable but dedicated wrappers exist for heavy federal work. This helps the agent decide when to choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search over the CURRENT Code of Federal Regulations (eCFR, keyless).
Unlike the GovInfo CFR collection (annual-edition snapshots), the eCFR
is amended through days ago and every hit carries the exact CFR hierarchy
(title/part/section) plus an excerpt.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | max results (default 20). | |
| query | Yes | full-text query, e.g. ``"unmanned aircraft"``. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds value by noting the eCFR is 'keyless' and provides exact hierarchy and excerpt, which is beyond what annotations convey. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. First sentence states purpose; second provides key differentiation and output details. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists (not shown but context confirms). Description mentions output includes hierarchy and excerpt. For a search tool, it is fairly complete, though it could mention pagination or result limits beyond the default.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both 'query' and 'limit' have descriptions in the input schema. The description does not add additional meaning beyond the schema examples. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it performs full-text search over the current Code of Federal Regulations (eCFR), distinguishing it from the GovInfo CFR collection (annual snapshots). The verb 'search' and resource 'CFR sections' are specific, and the differentiation clarifies its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description contrasts with GovInfo CFR (annual vs. current) but does not explicitly state when to use this tool over sibling search tools like us_search_federal_register or us_search_case_law. Usage context is implied but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search over Federal Register documents (1994-present, keyless).
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | full-text search query, e.g. ``"artificial intelligence"``. | |
| limit | No | max results (default 20). | |
| doc_type | No | optional filter - one of ``"RULE"``, ``"PRORULE"`` (proposed rule), ``"NOTICE"``, ``"PRESDOCU"`` (presidential document). | |
| presidential_document_type | No | optional filter for presidential documents - e.g. ``"executive_order"``, ``"proclamation"``, ``"memorandum"``. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds valuable context: date range (1994-present) and no key requirement, enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single clear sentence, front-loaded with key information (action, resource, scope). No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema, return values are covered. Sibling tools exist, and description aids differentiation. Adequate for a search tool with comprehensive schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented. Description mentions 'full-text search' which aligns with term parameter, but adds no extra meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (full-text search), the resource (Federal Register documents), and scope (1994-present, keyless). Distinct from sibling tools like us_search_bills or us_search_case_law.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives. However, name and description imply it's for Federal Register full-text search, providing implicit differentiation from sibling search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.5.3us_coveragev0.4.0us_get_billus_get_caseus_get_cfr_section_historyus_get_code_packageus_get_federal_register_docus_list_code_packagesus_search_billsus_search_case_lawus_search_cfr_sectionsus_search_federal_registerEach tool targets a distinct legal source and action: bills, code packages, Federal Register, case law, CFR sections, and a coverage tool. The search/get pairs are clearly separated by resource type, and even similar regulatory sources (Federal Register vs CFR) are distinct.
All tools follow the 'us_' prefix with a verb_noun pattern (search_, get_, list_). The only outlier is 'us_coverage', which uses a noun instead of verb_noun, and 'get_case' is shorter than 'get_federal_register_doc', but overall the pattern is consistent and predictable.
11 tools is well-scoped for a legal research connector covering multiple sources. Each tool serves a clear purpose, and the count is within the ideal 3-15 range, not feeling bloated or sparse.
The server provides search and retrieval for each major legal source: bills, code packages, Federal Register, case law, and CFR. The coverage tool explicitly identifies gaps and fallbacks, which mitigates incompleteness. Minor missing operations like a direct 'get CFR section' tool are workable through search and history tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Access U.S. congressional data - bills, votes, members, committees - via MCP.
An MCP server that provides congressional transcripts
Congress MCP — US Congress data via GovTrack API (free, no auth required)
GovTrack MCP — federal US Congress data (free, no auth)
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/matematicsolutions/us-eli-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
