Skip to main content
Glama

Court Delta

List North Carolina (NC) court cases filed by case type, county and date

list_cases_filed
Read-only

What was FILED — every case of a given type in a county over a date range.

Answers "what IF cases were filed in Surry County yesterday?", "show me the estate cases opened in Wake this week", "how many civil suits were filed in Mecklenburg on Monday?". This is the DOCKET axis. The other searches are name axes — use search_cases_by_party / _business / _attorney when you know WHO, and this when you know WHAT and WHEN.

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.

date_start/date_end are the FILED date, not a hearing date. A case filed in 2023 can have a hearing today — for "who is in court today", use get_attorney_hearing_calendar. Accepts YYYY-MM-DD, or the words "today" and "yesterday" (resolved in North Carolina (NC) time).

Defaults to YESTERDAY, not today, when no date is given, and says so in date_note. Today's filings are still being keyed in by clerks, so a "today" answer is a partial set that reads like a complete one.

case_type is a case-number PREFIX, not a type code. CR also returns CRS; CV also returns CVD and CVM. Read case_type_breakdown before reporting a count as "42 CR cases" — some of them may be CRS.

Common types: IF infraction (traffic), CR/CRS criminal, CV/CVD/CVM civil, E estate, SP special proceeding, M civil misc. judgment (liens, lis pendens).

Completeness. The portal caps a search at 200 cases; this splits the query by date and case-number prefix to get past that. If truncated is true the count is a LOWER BOUND, and incomplete_prefixes names the exact buckets that were not read — say what is missing rather than reporting the number as a total. The remedy is a shorter date range or a county.

An empty result is a real answer, but only when the lookup succeeded. On an upstream failure this returns an error; never report that as "nothing was filed".

county_filter: "server" means the county was applied by the portal itself before its cap, and every row is additionally checked against the county code embedded in its case number — so a county-filtered result here is exact, unlike the location-substring filter the name searches use.

A date range is required (max 31 days) — an unbounded search cannot be completed. Read-only public record, North Carolina only. Informational, not legal advice.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
countyNo
offsetNo
date_endNo
case_typeYes
date_startNo
case_statusNo

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?

Annotations only mark readOnly and openWorld hints; the description goes far beyond by revealing defaults (yesterday, not today), partial-data risks for today's filings, the 200-case portal cap with truncation semantics, the 'server' county filter guarantee, and the finer-grained case_status values. This is substantial behavioral context that annotations alone could not convey.

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 section earns its place by preventing real misuses: defaults, prefix semantics, truncation handling, and empty-result interpretation. It is front-loaded with the core purpose and sibling differentiation, then organized with clear bold labels, making the length navigable rather than bloated.

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, output schema availability, and the many edge-case traps, the description is remarkably complete. It addresses required date-range limits, truncation, incompleteness prefixes, error handling, county exactness, and status reporting rules, leaving no critical operational gap for an agent selecting or invoking the tool.

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?

Schema description coverage is 0%, so the description carries full weight for parameter meaning. It thoroughly explains date_start/date_end formats and semantics, case_type as a prefix rather than exact code, case_status granularity and prefix-matching requirement, and county_filter's 'server' special value. Only limit/offset lack explicit exposition, but their defaults and the portal-cap context make their role inferable.

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 leads with a specific verb and resource: 'What was FILED — every case of a given type in a county over a date range.' It immediately distinguishes itself from the sibling name-axis searches and provides concrete example questions, making it unmistakable which tool to invoke for docket-oriented lookups.

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 explicitly names alternatives: use search_cases_by_party/_business/_attorney when you know WHO, use get_attorney_hearing_calendar for today's hearings, and avoid lookup_court_case just for case status. It also clarifies when an empty result is a real answer versus an upstream failure, leaving no ambiguity about when to use this tool.

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