Court Delta

Screen up to 5 people for North Carolina (NC) court cases (counts only)

screen_names_by_party

Read-only

Triage a SHORT list of people for North Carolina (NC) court cases.

Built for the "here is a list of names, which ones have cases?" question — a CSV of applicants, tenants, or bond clients. This server cannot accept file uploads: read the file yourself and pass the names as an array.

Returns COUNTS AND FACETS PER NAME, not case detail — matched, case_count, counties, case_types, case_numbers (first few), portal_truncated. That keeps a 5-name response readable. Once you know which names are interesting, call search_cases_by_party (full rows) or lookup_court_case (one case) on those.

LIMITS, and why they are low: each name runs a LIVE portal search, and the upstream session token is shared by every user of this service — a wide fan-out risks blocking it for everyone. Max 5 names per call, 3 at a time. Split a longer list across calls.

SLOW BY NATURE: measured ~60s for 3 names and ~2 minutes for 5. Tell the user you're checking and roughly how long it takes; don't retry on a slow response, and don't treat the wait as an error. If your client's timeout is tight, send fewer names.

PARTIAL RESULTS ARE NORMAL: one name failing (portal hiccup, timeout) does not fail the batch — that entry comes back with an error and the rest still return. Report which names were checked and which weren't; never present a failed name as "no cases found", because those mean completely different things.

portal_truncated: true on a name means the portal hit its statewide 200-case cap, so that person's count is a LOWER BOUND — narrow with county, case_status, or a filed date range and re-run that name.

Dates: ISO YYYY-MM-DD or MM/DD/YYYY — both accepted. file_date_* bounds when the case was FILED, not when a hearing is scheduled.

Matching is exact on last + first name (no soundex here — it broadens results and would make a screening list noisier). A common name will match multiple different people; case_count is "cases matching this name", NOT "cases belonging to one person". There is no DOB or identity confirmation in this tool — do not treat a hit as identifying a specific individual.

Read-only. NC only. Public records. Informational, not legal advice.

Input Schema

Name	Required	Description
`names`	Yes	Up to 5 people, each with `last` and `first`. Returns counts only — triage a list, then look up the rows you care about.
`county`	No
`case_status`	No
`file_date_end`	No
`file_date_start`	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 / names / description

Added value: +"Up to 5 people, each with `last` and `first`. Returns counts only — triage a list, then look up the rows you care about."

addedInput schema / properties / names / examples

Added value: +[
+  [
+    {
+      "first": "JOHN",
+      "last": "SMITH"
+    },
+    {
+      "first": "JANE",
+      "last": "DOE"
+    }
+  ]
+]

First observedSep 8, 2026

TDQS

A4.9/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 goes well beyond them with operational traits: a shared upstream session token that limits fan-out (max 5 names, 3 concurrent), measured ~60s/~2min latency with an explicit don't-retry instruction, partial-batch failure semantics with per-name `error` entries, and `portal_truncated: true` meaning the count is a lower bound. It also flags that `case_count` is name-match count, not a person's case count — a critical misuse guard.

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?

Long but front-loaded and organized under CAPS headings (LIMITS, SLOW BY NATURE, PARTIAL RESULTS, Dates, Matching) that let an agent skim to the section it needs. Every paragraph carries distinct actionable information — limits, timing, failure handling, truncation, matching semantics — with no restatement of the title or schema.

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 slow, rate-limited, partially-failing open-world search, the description covers the prerequisites, cost, failure modes, and result interpretation an agent needs before calling it. Return-value meaning is explained inline even though an output schema exists, which is appropriate given the non-obvious `portal_truncated` and `error` fields.

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 20%, so the description carries most of the burden: it explains `names` as exact last+first matching with no soundex and no middle names, gives accepted date formats and clarifies that `file_date_*` bounds the filing date (not hearing date), and shows that `county`/`case_status`/date range are the narrowing levers for truncated results. It stops short of enumerating the allowed `case_status` values, which the schema does supply via enum.

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?

States a specific verb and resource (screen names for NC court cases) and immediately scopes it as a counts-only triage tool rather than a detail lookup. It explicitly names the follow-up siblings `search_cases_by_party` and `lookup_court_case` and the situation each is for, so an agent can separate this from its closest alternatives without opening a 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?

Frames the exact question it answers ("here is a list of names, which ones have cases?"), names the two alternative tools and when to move to them, and states the when-not cases (no file uploads, no soundex, no DOB/identity confirmation). It also tells the agent how to handle lists longer than the cap by splitting across calls.

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?