Skip to main content
Glama

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
courtNoOptional: limit to one district, as a code such as cacd, nysd or ilnd.
companyYesThe company or organisation name, for example "FedEx" or "Wells Fargo Bank". Whole words are matched; Inc, LLC and the like are optional.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
casesNoThe newest suits with court, case number, caption, date and link.
errorNoPresent only when the call failed: a code, a message and, where there is one, an action such as a link to give the user.
queryNoThe company searched for.
matchesNoMatching defendants with suit counts and districts.
coverageNoWhat the search covers and does not.
guide_urlNoThe guide to the kind of case this company is usually sued in, or null.
next_stepNoWhat to do next.
total_suitsNoHow many new suits name the company.
window_daysNoHow many days back the search covers.
what_it_doesNoWhat that alert is and what it costs.
watch_new_suits_urlNoWhere the user can get an email whenever a new suit names the company.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / guide_url
      Added value: +{
      +  "description": "The guide to the kind of case this company is usually sued in, or null."
      +}
  2. Changed1 schema field changed
    • 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"
      +}
  3. Added

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources