Skip to main content
Glama

Court Delta

Find a company's court cases by business name

search_cases_by_business
Read-only

Cases with a COMPANY as a party — by business name.

Use this, not search_cases_by_party, whenever the subject is an organization: an LLC, corporation, insurer, hospital, landlord, dealership or municipality. Party search requires a first AND last name, which a business does not have, so it cannot answer this at all.

FAST — about 5-45 seconds. No CAPTCHA. Do not warn about a long wait.

EVERY ROW NOW CARRIES case_status, with no enrich needed — so do not call lookup_court_case merely to find out whether a case is open or closed. The returned text is FINER-GRAINED than the four filter values: alongside "Pending" and "Disposed" you will see "Disposed - Voluntary Dismissal", "Disposed - Dismissal on Order of the Court", "Disposed - Clerk of Superior Court" — i.e. HOW it ended, not just that it did. So never test it with equality against the filter vocabulary (status == "Disposed" misses most disposed rows); match on a prefix, and quote the portal's own wording when you report it.

TYPE THE NAME AS IT APPEARS, COMMA INCLUDED. The comma is significant and NARROWING: "FOOD LION, LLC" is a different, smaller search than "FOOD LION". Do not strip it, and do not replace it with a wildcard — advice to do that appears in the portal's help text but applies to a different search mode.

WILDCARD: a trailing * is allowed and needs AT LEAST 4 characters before it. "WALM*" works; "WAL*" is rejected. Use it for a company whose exact registered name you do not know ("CAROLINA TOWING*").

THERE IS NO PARTY ROLE IN THIS RESULT, ON PURPOSE. The portal labels every row "Defendant" regardless of the truth — including cases the company FILED as plaintiff and criminal cases where it was the victim. NEVER say the business is the defendant. Read the side from case_name ("X VS Y" — the company's position in the caption is the real signal), or call lookup_court_case for the actual party list.

THE 200-CASE CAP BITES IMMEDIATELY FOR ANY CHAIN OR INSURER. results_truncated: true means real matches are MISSING. Worse, county filters AFTER that cap, so a truncated county-filtered count is a LOWER BOUND, never a total — "11 cases in Wake" may be 11 of the 200 statewide the portal was willing to show. Only case_status and the file-date range narrow server-side. Say the list is incomplete instead of reporting a count as if it were complete.

matched_businesses lists the distinct entity names actually hit. More than one means legally separate entities are mixed together ("FOOD LION, LLC" alongside "DELHAIZE AMERICA, LLC") — surface that rather than treating them as one company.

Dates: ISO YYYY-MM-DD or MM/DD/YYYY — both accepted. These bound WHEN THE CASE WAS FILED, not when anything is scheduled. A year at a time is the most effective way to get a chain's cases under the 200-cap: 'FOOD LION' unfiltered caps out, but restricted to 2023 it returns 42 complete rows.

Public record. Read-only. North Carolina (NC) only. Informational, not legal advice.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
limitNo
countyNo
case_statusNo
file_date_endNo
file_date_startNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

The description discloses extensive behavioral traits beyond the annotations. It reveals that the tool is fast (5-45 seconds), has no CAPTCHA, that case_status rows are finer-grained than filter values (so equality checks fail), that there is no party role (every row labeled 'Defendant' incorrectly), that the 200-case cap affects results and county filters happen after truncation, and that matched_businesses lists distinct entities. It also explicitly states 'Public record. Read-only.' which aligns with the readOnlyHint annotation. 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.

Conciseness5/5

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

The description is long but every sentence carries essential information. It is structured with clear sections and emphasis (bold, caps) to highlight pitfalls and constraints. The primary purpose and alternative are front-loaded, followed by critical usage rules and edge cases. There is no filler; each clause adds value.

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's complexity (6 parameters, output schema, many potential pitfalls), the description is remarkably complete. It covers usage guidelines, behavioral expectations, parameter nuances, and result semantics (e.g., case_status granularity, matched_businesses meaning). It also warns against common mistakes (e.g., not testing equality with filter vocabulary, not claiming the business is the defendant). With an output schema present, the description needn't explain return structure, but it still clarifies result semantics. Nothing an agent needs to call this tool correctly is missing.

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?

Although schema description coverage is 0%, the description adds critical semantics for each parameter: name must be typed as it appears with the comma included; limit is not mentioned but default is in schema; county filter happens after the 200-case cap (so counts are lower bounds); case_status values are broad but actual results are more detailed; file_date_start/end bound filing dates and accept two formats. The description also explains wildcard behavior (at least 4 chars before *) and recommends yearly filtering to stay under the cap. This far exceeds what the schema provides.

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 states a specific verb and resource: find court cases by business name. It explicitly differentiates from sibling search_cases_by_party by specifying that this tool is for organizations (LLC, corporation, insurer, etc.) and that party search requires first and last names. The purpose is unambiguous and well-scoped.

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

Usage Guidelines5/5

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

The description provides explicit when-to-use and when-not-to-use guidance: 'Use this, not search_cases_by_party, whenever the subject is an organization.' It explains why the alternative fails for businesses. It also gives detailed usage tips: comma significance, wildcard rules, date formats, the 200-case cap, and how to handle truncation and county filters. These are actionable instructions that guide correct invocation.

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