Skip to main content
Glama
Sign In

Federal Civil

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Federal Civil Search

federal_civil_search
Read-onlyIdempotent

Find US FEDERAL CIVIL LAWSUITS by party name. Searches federal district court civil dockets, no API key — contract disputes, civil rights, employment, product liability, ERISA, social security appeals and prisoner petitions. Returns case caption, docket number, district, filing and termination dates, assigned judge, and the nature-of-suit code where the court recorded one. Use for "is this company being sued in federal court" and litigation exposure checks. A party search also runs a live, token-less CourtListener search for anything filed after the snapshot_date the bulk data carries and merges it in, so a suit filed last week is found; those rows are marked coverage:"live" and carry the full party list, which catches a derivative suit captioned against officers rather than the company. A case REMOVED from state court carries a removed_from object giving the originating state court and its state docket number, so the state and federal records can be linked — a removal is otherwise invisible on a federal docket, whose cause code describes the federal statute invoked rather than where the case came from.

Input Schema

NameRequiredDescriptionDefault
courtNoOptional federal district id, e.g. "cand", "nysd", "ilnd".
limitNoMaximum dockets to return (1-50, default 10).
partyYesParty name or a distinctive part of it, e.g. "Monsanto".
filed_afterNoOnly cases filed on or after this date, YYYY-MM-DD.
filed_beforeNoOnly cases filed on or before this date, YYYY-MM-DD.
check_removalNoLook up which state court each case was removed from (default true). Set false to skip one upstream request per call when you do not need it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / check_removal
      Added value: +{
+  "description": "Look up which state court each case was removed from (default true). Set false to skip one upstream request per call when you do not need it.",
+  "type": "boolean"
+}
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses that no API key is needed, that a party search also runs a live token-less CourtListener query past the snapshot_date and merges results, that live rows are tagged coverage:"live" and carry a full party list (catching derivative suits captioned against officers), that removed cases carry a removed_from object, and that check_removal costs one upstream request per call. That is exactly the behavioral context annotations cannot express.

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?

Purpose and scope are front-loaded in the first sentence, and the remaining sentences each carry distinct information (return fields, use cases, live merge, removal linkage). It is dense and long for a single paragraph, with a few clauses that could be tightened, but there is little pure filler.

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?

With no output schema, the description enumerates the returned fields (caption, docket number, district, filing/termination dates, judge, nature-of-suit code) and explains the two non-obvious data-shape cases (coverage:"live" rows, removed_from objects). An agent has everything needed to call and interpret results.

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?

Schema coverage is 100%, so the baseline is 3; the description earns above that by explaining the operational consequence of check_removal (one upstream request per call, skip when unnecessary) and by making clear that the live merge is triggered by the party search itself. It adds contextual meaning rather than restating field docs.

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?

States a specific verb and resource ('Find US FEDERAL CIVIL LAWSUITS by party name'), enumerates the covered subject matter (contract, civil rights, employment, ERISA, etc.) and names the data source (federal district court civil dockets). An agent can distinguish it from federal_civil_recent purely from this text.

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?

Gives concrete use cases ('is this company being sued in federal court', litigation exposure checks), which is strong context. It does not, however, name the sibling federal_civil_recent as the alternative for recency-focused queries or state any exclusion, so it stops short of explicit routing guidance.

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

All Federal Civil toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources