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

Name	Required	Description
`limit`	No
`county`	No
`offset`	No
`date_end`	No
`case_type`	Yes	1-4 letters: IF (infraction), CR/CRS (criminal), CV (civil), E (estate), SP (special proceeding), M (magistrate).
`date_start`	No
`case_status`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 6, 2026

addedInput schema / properties / case_type / description

Added value: +"1-4 letters: IF (infraction), CR/CRS (criminal), CV (civil), E (estate), SP (special proceeding), M (magistrate)."

addedInput schema / properties / case_type / examples
```
Added value: +[
+  "IF",
+  "CR",
+  "CV"
+]
```

First observedSep 8, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description adds substantial operational context beyond them: defaults to YESTERDAY (with date_note), 200-case portal cap with date/prefix splitting, truncated means a LOWER BOUND with incomplete_prefixes naming missing buckets, error vs. genuine empty result distinction, server-side county filtering exactness, and a 31-day max range. This is far more than the annotations carry.

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?

Long, but front-loaded with the core definition and each paragraph carries distinct operational guidance (status vocabulary, date semantics, truncation, error handling) rather than filler. Some emphasis-heavy phrasing and illustrative example queries add length without adding much, keeping it short of a 5.

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?

An output schema exists, so return values need no explanation; the description instead covers the failure and edge modes an agent must handle — truncation as a lower bound, upstream error vs. empty result, prefix-based case_type counts, and finer-grained case_status values that must not be matched with equality against the filter enum. Nothing needed to call it correctly is missing.

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 description coverage is only 14%, so the description must compensate, and it does for the highest-value params: date_start/date_end are the FILED date (not hearing), accept YYYY-MM-DD or 'today'/'yesterday' in NC time, and case_type is a case-number prefix (CR also returns CRS) with a type legend. limit and offset are never explained, leaving a real gap for paging behavior.

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?

Opens with a specific verb and resource plus scope: 'What was FILED — every case of a given type in a county over a date range,' and explicitly frames this as the DOCKET axis. It names the sibling tools it is not (search_cases_by_party/_business/_attorney) and the axis each covers, so an agent can route without opening any schema.

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?

Gives explicit selection rules: use the name searches 'when you know WHO' and this one 'when you know WHAT and WHEN.' It also rules out misuse — do not call lookup_court_case just to learn open/closed status, and use get_attorney_hearing_calendar for 'who is in court today.' Exclusions and alternatives are both present.

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

All Court Delta 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?