search_cases_by_party

shallow

com.courtdelta/court-delta · Verify this server

Search North Carolina (NC) court cases by a person's name. Returns (person, case) matches from the NC eCourts party-name search. Each row carries a `case_number` (the stable id) and a `portal_session_ref` — a Tyler token whose lifetime is UNSPECIFIED (it rotates every search; survives at least minutes; upper bound unmeasured). Pass it to `lookup_court_case` (as `portalSessionRef`) for a quick follow-up; for anything persisted or delayed use `case_number`. Never persist or reuse the ref. Each row also carries `portal_url` — the direct NC eCourts source record; it embeds the same short-lived token, so treat it like the ref (don't persist). `caseSummaryUrl` (from `lookup_court_case`) is the durable link. 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. Rows carry `party_type` (the person's role) plus `party_role_source`: "caption" = surname confirmed in the case caption (trust it); "portal_party_type" = role from the portal's own PartyTypeKey but no caption to confirm (common on SP / foreclosure cases — usable, but corroborate for high-stakes use); null = no role (or a role dropped as suspect, e.g. a citing officer mislabeled "Defendant" on someone else's caption). For an AUTHORITATIVE role/roster, call `lookup_court_case` and read its `parties` list. `party_role_verified` (bool) = source == "caption". Read-only. NC only. Informational, not legal advice. Required: `last`, `first`. Filters differ in where they apply: - SERVER-SIDE narrowing (reduce the portal search — the ONLY way to clear the 200-case cap): `case_status` ("Pending"|"Disposed"|"Closed"|"Reopened"), the filed-date range `file_date_start`/`file_date_end` (ISO YYYY-MM-DD or MM/DD/YYYY — both accepted), and a more specific name. - `soundex: true` is also server-side but BROADENS (phonetic surname matching → MORE matches, more likely to truncate) — don't enable it to clear a cap. - CLIENT-SIDE (filter the rows already returned; do NOT recover cases missed by the cap): `county` ("Wake" or "Wake County") and `case_type` (pick a value from the `narrowing.caseTypes` facet). Speed: a search runs a live portal query and takes ~15-50s, with real run-to-run variance — do NOT pick filters for speed. Narrow for COMPLETENESS: `case_status` and a `file_date` range are server-side and are the only filters that recover cases past the 200-cap; `county`/`case_type` only filter what was already returned. Two different limits: - `portal_truncated` true = the portal hit its statewide 200-case cap, so the set is INCOMPLETE (real matches are missing). See `portal_truncated_note`; when true, `narrowing` gives counties only (counts are lower bounds). Clear it with `case_status` / date range / a more specific name. - `results_truncated` true = the (complete) set exceeded `limit`, so not all rows are shown. Pass a higher `limit` (up to 200) to show them all. Breadth (read `narrowing_hint`): the tool never asks you to withhold results, and it distinguishes two cases with different remedies: - INCOMPLETE (`portal_truncated` true): the shown cases are valid but some are missing. Present them, and to recover the rest narrow with server-side filters (a filed-date range or `case_status`) — or, if autonomous with no user to ask, re-call `confirm_broad=true` to proceed as-is. - COMPLETE but long (a large set with `portal_truncated` false): nothing is missing. List or summarize the results; refining (county/case_type/date) is optional, not required. A moderate complete set is a fine answer on its own.

100.0/100

1 trials · measured 27 days ago

search_cases_by_party scores 100.0/100 on Vouch's measured behaviour index, from 1 real invocation trials against com.courtdelta/court-delta, measured 11 Sept 2026 under methodology v0.2.0. Every measured component scored 100.

Component breakdown

ComponentWeightValue
Reliability35%not applicable
Schema integrity25%100.0
Failure behaviour15%not applicable
Latency15%not applicable
Concurrency10%not applicable

Tool details

Transport
remote
Credential class
open
Input schema
not declared
Output schema
not declared
Side-effect classification
unclassified

Score history

DayScoreTierMethodology
2026-09-11100.0shallowv0.2.0

Probe evidence

ProbeOutcomes
schema_integritypass: 1

Raw request/response logs are not archived yet — the outcome counts above are drawn directly from every recorded trial.

Embed this score

Available for every tool, scored or not — not a verification perk. Always links back to this page.

Vouch score: search_cases_by_party
[![Vouch score](https://vouch.tools/api/tools/b1dc81e1-d812-4f83-8089-ffe66725eeef/badge.svg)](https://vouch.tools/tools/b1dc81e1-d812-4f83-8089-ffe66725eeef)
search_cases_by_party — Vouch