Skip to main content
Glama

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

TableJSON Schema
NameRequiredDescriptionDefault
namesYes
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

A4.9/5.0
Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description adds substantial behavioral context: live portal searches with a shared upstream token, slow responses (~60s for 3 names, ~2 min for 5), partial batch failures with per-name errors, portal_truncated as a lower bound, exact matching with no soundex, and no identity confirmation. No statement contradicts the annotations.

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, covering limits, latency, partial results, truncation semantics, date formats, matching behavior, and disclaimers. The structure uses clear categorical labels and front-loads the primary purpose before caveats, making it scannable despite its length.

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 and the existence of an output schema, the description is remarkably complete: it covers rate-limit rationale, slow-response expectations, partial-failure behavior, truncation, date interpretation, exact-match semantics, identity limitations, and jurisdiction. 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With schema description coverage at 0%, the description carries the burden of explaining parameters. It explains that county, case_status, and file_date_* are narrowing filters, defines file_date_* as filing-date bounds, and specifies accepted date formats. It does not detail county value formatting or the effect of leaving filters null, but it compensates well for most of the schema's silence.

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 opens with a specific verb and resource: 'Triage a SHORT list of people for North Carolina (NC) court cases.' It immediately identifies the exact use case ('which ones have cases?') and explicitly distinguishes itself from siblings like search_cases_by_party and lookup_court_case by stating it returns counts and facets, not case detail.

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 states when to use this tool, what not to do ('This server cannot accept file uploads'), and names the alternatives: call search_cases_by_party for full rows or lookup_court_case for one case. It also gives concrete usage constraints: max 5 names per call, 3 at a time, split longer lists, and don't retry on slow responses.

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