CaseMagic — Federal Court Case Lookup & Monitor

Find new lawsuits against a company

find_lawsuits_against_company

Read-onlyIdempotent

Find new federal lawsuits filed against a company or organisation in the last 30 days: how many, in which district courts, and the newest cases with their case numbers and captions. Use when the user asks whether a company is being sued, "lawsuits against ", "has anyone sued " or "new cases against ". Read from the federal district courts' public filing feeds; organisations only, never people; state courts and older suits are not covered. The result includes a link for an email whenever a new suit names the company. Free, no account.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "company": "<company>"
    },
    "name": "find_lawsuits_against_company"
  }
}

Input Schema

Name	Required	Description	Default
`court`	No	Optional: limit to one district, as a code such as cacd, nysd or ilnd.
`company`	Yes	The company or organisation name, for example "FedEx" or "Wells Fargo Bank". Whole words are matched; Inc, LLC and the like are optional.

Output Schema

Name	Required	Description
`cases`	No	The newest suits with court, case number, caption, date and link.
`error`	No	Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user.
`query`	No	The company searched for.
`matches`	No	Matching defendants with suit counts and districts.
`coverage`	No	What the search covers and does not.
`guide_url`	No	The guide to the kind of case this company is usually sued in, or null.
`next_step`	No	What to do next.
`total_suits`	No	How many new suits name the company.
`window_days`	No	How many days back the search covers.
`what_it_does`	No	What that alert is and what it costs.
`watch_new_suits_url`	No	Where the user can get an email whenever a new suit names the company.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 7, 2026

addedOutput schema / properties / guide_url

Added value: +{
+  "description": "The guide to the kind of case this company is usually sued in, or null."
+}

Changed1 schema field changedOct 5, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "cases": {
+      "description": "The newest suits with court, case number, caption, date and link.",
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "coverage": {
+      "description": "What the search covers and does not.",
+      "type": "string"
+    },
+    "error": {
+      "additionalProperties": true,
+      "description": "Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user.",
+      "properties": {
+        "code": {
+          "description": "Machine-readable error code, for example CASE_NOT_FOUND or MULTIPLE_CASES_FOUND.",
+          "type": "string"
+        },
+        "message": {
+          "description": "What went wrong, in a sentence.",
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "matches": {
+      "description": "Matching defendants with suit counts and districts.",
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "next_step": {
+      "description": "What to do next.",
+      "type": "string"
+    },
+    "query": {
+      "description": "The company searched for.",
+      "type": "string"
+    },
+    "total_suits": {
+      "description": "How many new suits name the company.",
+      "type": "number"
+    },
+    "watch_new_suits_url": {
+      "description": "Where the user can get an email whenever a new suit names the company.",
+      "type": "string"
+    },
+    "what_it_does": {
+      "description": "What that alert is and what it costs.",
+      "type": "string"
+    },
+    "window_days": {
+      "description": "How many days back the search covers.",
+      "type": "number"
+    }
+  },
+  "type": "object"
+}

AddedOct 4, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare the read-only, idempotent, open-world, non-destructive profile, yet the description adds substantial extra context: the data source (federal district courts' public filing feeds), the 30-day freshness window, the organisations-only limitation, coverage gaps (state courts, older suits), an email-link side effect, and free/no-account access. This is well beyond what the 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.

Conciseness4/5

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

The purpose is front-loaded in the first sentence and every subsequent sentence earns its place by adding scope, usage, or source information. It is somewhat dense with semicolon-joined clauses, which slightly reduces scannability.

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 filtered-lookup tool with an output schema that documents return values, the description supplies everything else an agent needs: what it returns in summary terms, the time window, the entity restriction, the data source, and the coverage gaps. Nothing material is missing.

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

Parameters3/5

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 both parameters (company whole-word matching, court as a district code such as cacd/nysd). The description only echoes the district dimension without adding syntax or format detail, so it meets the baseline rather than exceeding it.

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?

Names a specific verb and resource (find new federal lawsuits against a company) with a defined time window (last 30 days) and output scope (count, districts, newest cases with case numbers and captions). This is clearly distinguishable from case-level siblings like get_case_docket or find_federal_case, which operate on known case identifiers rather than a company name.

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?

Provides explicit trigger phrases ('is <company> being sued', 'lawsuits against <company>', 'new cases against <company>') and clear scope exclusions (people, state courts, older suits). It doesn't name or re-route to any sibling tool, so the alternative-selection element is missing, keeping it just short of a 5.

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

All CaseMagic — Federal Court Case Lookup & Monitor tools Inspect

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

Need Help?